On 1 June 2013 02:32, Jonathan M Davis <[email protected]> wrote: > On Friday, May 31, 2013 19:42:55 Manu wrote: > > On 31 May 2013 14:06, deadalnix <[email protected]> wrote: > > > On Friday, 31 May 2013 at 02:56:25 UTC, Andrei Alexandrescu wrote: > > >> On 5/30/13 9:26 PM, finalpatch wrote: > > >>> https://dl.dropboxusercontent.**com/u/974356/raytracer.d< > https://dl.drop > > >>> boxusercontent.com/u/974356/raytracer.d> > > >>> https://dl.dropboxusercontent.**com/u/974356/raytracer.cpp< > https://dl.d > > >>> ropboxusercontent.com/u/974356/raytracer.cpp>>> > > >> Manu's gonna love this one: make all methods final. > > > > > > I don't think going as far as making thing final by default make sense > at > > > this point. But we sure need a way to be able to finalize methods. We > had > > > an extensive discussion with Don and Manu at DConf, here are some idea > > > that > > > > > > came out : > > > - Final by default > > > > > > This one is really a plus when it come to performance code. However, > > > virtual by default have proven itself very useful when performance > isn't > > > that big of a deal (and it is the case for 90% of a program's code > > > usually) > > > and limiting the usage of some pattern like decorator (that also have > been > > > proven to be useful). This is also huge breakage. > > > > The correct choice :) > > > > > virtual by default have proven itself very useful when performance > isn't > > > > that big of a deal > > > > Has it? I'm not sure it's ever proven its self useful, can you point to > any > > such proof, or evidence? > > It's useful when you don't have override, because you avoid the problem of > overriding non-virtual functions. So, going with virtual by default solves > that nasty bug, but enforcing override _also_ solves it. So IMHO, requiring > override (which we already do) solves the problem, making it pointless to > make > member functions virtual by default. At that point, it just makes more > sense > to make them non-virtual by default and avoid the performance issues > caused by > virtual by default. The _only_ thing that it costs you is that it forces > you > to put virtual on all functions which are going to be overridden, which is > even fewer functions than we have to mark with override (because multiple > classes can override whereas only the base class function would be marked > with > virtual). > > > There's another detail that came up late at night at dconf; I was talking > > to Daniel Murphy about the extern(C++) class work he's working on to > write > > the D-DMD front end, and apparently it would make the problem a lot > easier > > if virtual was explicit there too. So perhaps it also offers improved > > interoperability with C++, which I think most of us have agreed is of > > heightened importance recently. > > Yes. I intend to create a DIP for non-virtual by default (assuming that no > one > else does first), and I think that this issue gives even more weight to > why we > need to make the change. > > > > This is also huge breakage. > > > > I think this is another fallacy. The magnitude of the breakage is already > > known. It's comparable to the recent change where 'override' became an > > explicit requirement, which was hardly catastrophic. > > In that case, the breakage occurred in *every derived class*, which is a > > many:1 relationship to base classes. > > Explicit virtual would only affect _base_ classes. The magnitude of which > > is far smaller than what was recently considered acceptable, precisely: > > magnitudeOfPriorBreakage / numberOfDerivedClasses. > > > > So considering explicit override was an argument won, I'd like to think > > that explicit virtual deserves the same treatment for even more > compelling > > reasons, and at a significantly lesser cost in breakage. > > Yes. The breakage is surprisingly small, and the change is arguably > critical > for both performance-critical code and for moving the compiler frontend to > D. >
**applause** Someone other than me said it, out loud! This is a magnificent day! :)
