On Thu, Jan 5, 2023 at 10:01 PM Brian Bi <bbi5291@gmail.com> wrote:
> No.
>
> There's no legitimate reason to restrict what the author of B can make
> one of its non-virtual functions do. As such, there should not be a
> language-level mechanism for it.
The following program fails to compile:
struct A {
virtual int Func(void) final { return 5; }
};
struct B : A {
int Func(void) { return 6; }
};
int main(void)
{
B obj;
}
Note here that the person who wrote 'B' didn't necessarily know that
'A' had a virtual function called 'Func', but nonetheless 'B' is
restricted in what it can do. So it won't be that much different
restricting non-virtual functions also.
I think you meant to send this to the list, not to me.
Sure, if you declare a virtual method `final`, then you restrict what derived classes can do, but the difference is that there's actually a legitimate reason for the restriction. If I have
int foo(A& a) { return a.Func(); }
and `A::Func` is final, then the compiler can devirtualize the call. In addition, the writer of this code can rely on the guarantee that `a.Func()` has the same value and side effects as `a.A::Func()`. If any other functions in `A` call `A::Func`, then they, too, can rely on such guarantees.
On the other hand, if `Func` is non-virtual, then those guarantees already hold; having the ability to prevent a derived class from declaring a method with the same name does not strengthen them. As such, it is a restriction that gives nothing in return.
--