<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 13 March 2014 03:47, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On 3/11/14, 8:04 PM, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'm really trying to keep my lid on here...<br>
</blockquote>
<br></div>
Yep, here we go again :o).</blockquote><div><br></div><div>*sigh*</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I'll just remind that in regard to this particular point which sounds<br>
reasonable, it's easy to forgot that *all library code where the author<br>
didn't care* is now unusable by anybody who does. The converse would not<br>
be true if the situation was reversed.<br>
</blockquote>
<br></div>
There's an asymmetry introduced by the fact there's today code in use.</blockquote><div><br></div><div>Do you think the deprecation path is particularly disruptive? It can be implemented over a reasonably long time.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
virtual-by-default is incompatible with optimisation, and it's reliable<br>
to assume that anybody who doesn't explicitly care about this will stick<br>
with the default, which means many potentially useful libraries may be<br>
eliminated for use by many customers.<br>
</blockquote>
<br></div>
Virtual by default is, however, compatible with customization and flexibility.<br></blockquote><div><br></div><div>I completely disagree with the everything-should-be-virtual idea in principle; I think it's dangerous and irresponsible API design, but that's my opinion.<br>
</div><div>Whether you are into that or not, I see it as a design decision, and I think it's reasonable to make that decision explicit by typing 'virtual:'.</div><div><br></div><div>What's not subjective, is that the optimiser can't optimise virtual-by-default. That's just a fact, and one which I care about deeply.</div>
<div>I think it's also statistically reliable that people will stick with the default in almost all cases.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Unstated assumption: "many potential useful libraries" assumes many libraries use traditional OO design in their core components.<br></blockquote><div><br></div><div>In my experience; physics, sound, scene graph... these sorts of things are common libraries, and also heavy users of OO. Each of those things are broken into small pieces implemented as many objects.<br>
If people then make use of properties, we're in a situation which is much worse than what we already struggle with in C++.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

Unstated assumption: "many customers".</blockquote><div><br></div><div>Do I need to quantify?</div><div><br></div><div>I work in a gigantic industry. You might call it niche, but it's like, really, really big.</div>
<div>I often attend an annual conference called GDC which attracts multiple 10s of thousands of developers each year. It's probably the biggest software developer conference in the world.</div><div>A constantly recurring theme at those conferences is low-level performance on embedded hardware, and specifically, the mistakes that PC developers make when first moving to embedded architectures.<br>
</div><div>There's a massive audience for these topics, because everyone is suffering the same problems. Virtual is one of the most expensive hazards, just not on x86.</div><div>Most computers in the world today don't run x86 processors.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Also, as discussed at length, revoking virtual from a function is a<br>
breaking change, adding virtual is not.<br>
</blockquote>
<br></div>
Changing the default is a breaking change.</blockquote><div><br></div><div>Yes, but there is an opportunity for a smooth transition and elimination of the problem, rather than committing to consistent recurrence of breaking libraries in the future whenever anyone wants to optimise in this way.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Which means that, instead of<br>
making a controlled breaking change with a clear migration path here and<br>
now, we are committing every single instance of any user's intent to<br>
'optimise' their libraries (by finalising unnecessarily virtuals) to<br>
breaking changes in their ABI - which *will* occur, since virtual is the<br>
default.<br>
</blockquote>
<br></div>
Unstated assumption: "every single instance" assumes again that people interested in writing fast libraries have virtual calls as a major bottleneck, and furthermore they didn't care about speed to start with, to wake up later. This pictures library designers as quite incompetent people.</blockquote>
<div><br></div><div>YES! This is absolutely my professional experience! I've repeated this many times.</div><div>Many(/most) libraries I've wanted to use in the past are written for a PC; rarely any real consideration for low-level performance.</div>
<div>Those that are tested for cross-compiling are often _originally_ written for a PC; API is architecturally pre-disposed to poor performance.</div><div><br></div><div>This is precisely the sort of thing that library authors don't care about until some subset of customers come along that do. At that point, they are faced with a conundrum; breaking the API or ignoring the minority - which can often take years to resolve, meanwhile buggering up our schedule or wasting our time re-inventing some wheel.</div>
<div>PC programmers are careless programmers on average. Because x86 is the most tolerant architecture WRT low-level performance by far, unless library authors actively test their software on a wide variety of machines, they have no real bearing to judge their code.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
According to semantic versioning, this requires bumping the major<br>
version number... that's horrible!<br>
</blockquote>
<br></div>
Appeal to emotion.</blockquote><div><br></div><div>Bumping major version numbers is not an emotional expression. People take semantic versioning very seriously.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
What's better; implementing a controlled deprecation path now, or<br>
leaving it up to any project that ever uses the 'class' keyword to<br>
eventually confront breaking changes in their API when they encounter a<br>
performance oriented customer?<br>
</blockquote>
<br></div>
It's better to leave things be. All I see is the same anecdote gets vividly told again whenever the topic comes up.</blockquote><div><br></div><div>Whatever.<br></div></div></div></div>