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