On Fri, May 01, 2015 at 05:05:09AM -0700, finnbry...@gmail.com 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 > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform