On Fri, May 01, 2015 at 05:05:09AM -0700, [email protected] wrote:
> On Friday, May 1, 2015 at 12:03:35 PM UTC+1, Aryeh Gregor wrote:
> > On Thu, Apr 30, 2015 at 6:49 PM, Trevor Saunders wrote:
> > > I don't think it would actually be backward incompatible the only
> > > changes would be turning invalid programs into valid ones.
> >
> > Given that "void foo() override;" currently makes foo() a virtual
> > function, allowing override on non-virtual functions would have to
> > change the meaning to make foo() non-virtual.
>
> Not exactly, afaict, since it would also produce an error in any case where
> foo wasn't *already* implicitly a virtual. So adding override can only add
> additional information in the case where it causes an error. And since nobody
> cares (from a general pov) about turning invalid programs into valid ones, it
> could theoretically be changed in a future C++ version.
>
> That said, it won't happen, since the entire purpose of override is to allow
> programmers to explicitly confirm that they are overriding a virtual method
> from a superclass, so allowing override for a method that doesn't override a
> virtual is completely nonsensical. If it was valid for methods that didn't
> override, it would act exactly the same as virtual, so would serve no
> purpose, unless it counted as "virtual only if overriding a virtual,
> otherwise non-virtual", in which case it would be identical to the implicit
> behavior, except it would cause huge confusion if applied to a non-overriding
> method. So you can probably trust that will never happen.
there is no reason override has to mean that you are overriding a
virtual method as opposed to overriding a non virtual member. Consider
this program
struct Base
{
bool IsAFoo() { return mIsAFoo; }
bool mIsAFoo;
};
struct Foo
{
bool IsAFoo() { return true; }
};
One might wish to mark Foo::IsAFoo override so the compiler checks it
shadows Base::IsAFoo but both are still non virtual.
> As for final, final attempts to prevent any subclasses from overriding a
> virtual method. You can't override a non-virtual, so final on a non-virtual
> would serve no purpose (except perhaps to prevent all subclasses from reusing
> a method name and hiding the superclasses method? but that seems like
> something that should be avoided regardless and is better solved with a
> compiler-warning than a language feature...).
your exception here is correct, there's no reason final needs to be
specific to virtual overriding. There are good use cases for non
virtual overriding, so a compiler warning doesn't seem like a great idea
unless you have some sort of attribute to opt out maybe, at which point
why not put something in the standard so it works on all compilers?
Now, I don't think I care enough about this to write a proposal for it,
but I think it would be nice if the committee did it on its own.
Trev
> _______________________________________________
> dev-platform mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
