On 11/7/22 19:23, Paul Fee via Std-Proposals wrote:
> 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.

Aiding refactoring is a job for tooling (e.g. IDE or some kind of
linter). For example, some IDEs are able to highlight virtual functions
and overrides. Changing the core language for this doesn't sound like
the right approach to me.