Hi Paul,

> I'd like the compiler to confirm that the member function does NOT
> override a base class function, then I'd be able to follow up with
> broader refactoring knowing the impact of the change is limited to
> just one class.

If your only concern is refactoring, you may also mark member function
Derived::state() as override and refactor it if the compiler issues an
error. Os is there any other point I missed in your proposal?

Best,
Paolo

Il giorno lun 7 nov 2022 alle ore 17:24 Paul Fee via Std-Proposals <
std-proposals_at_[hidden]> ha scritto:

> Hello,
>
> The "final" and "override" specifiers can be useful to ensure code using
> inheritance is implemented as expected. However there are some gaps where
> I find some features lacking, I can't express some approaches nor get the
> compiler to confirm my assumptions. When refactoring large codebases, one
> may wish to make an isolated API change but inadvertently changes code
> that's part of a class hierarchy. Some additional specifiers may allow
> developers to proceed with caution, protecting them before breaking
> functionality.
>
> Example:
>
> struct Base
> {
> virtual bool state() { return false; }
> };
>
> struct Derived : public Base
> {
> bool state() { return s; }
> private:
> bool s = false;
> }
>
> One may opt to refactor state() to make it a const method, without
> noticing there's also an implementation in the base class as "virtual" is
> only necessary in the base class. Such a change should be applied
> consistently throughout the hierarchy. I'd like the compiler to confirm
> that the member function does NOT override a base class function, then I'd
> be able to follow up with broader refactoring knowing the impact of the
> change is limited to just one class. The final specifier means I don't
> need to look further down the class hierarchy, but I don't have a specifier
> that ensures I don't need to look up the hierarchy.
>
> Step 1: If this still compiles, then we know there'll be no surprises when
> changing the API.
> struct Derived final : public Base
> {
> bool state() !override { return s; }
> private:
> bool s = false;
> }
>
> Step 2: state function signature can be safely changed.
> struct Derived final : public Base
> {
> bool state() const !override { return s; }
> private:
> bool s = false;
> }
>
> Here !override is use as example syntax, but that was just to illustrate
> the idea. When refactoring, step 1 would fail to compile because
> Derived::state() does override Base::state(). This alerts the developer to
> the danger of only changing the derived class.
>
> Would it be reasonable to enhance the set of specifiers so that more
> scenarios can be expressed, allowing the compiler to confirm if the
> developer's assumptions are correct? For example:
>
> * function must/must not override a base class function
> * function must/must not be part of a group of overloads
> * function must/must not be virtual
>
> Thanks,
> Paul
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>