<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 March 2014 07:28, Dicebot <span dir="ltr"><<a href="mailto:public@dicebot.lv" target="_blank">public@dicebot.lv</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=""><div class="h5">On Tuesday, 11 March 2014 at 21:24:22 UTC, bearophile 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">
Dicebot:<br>
<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">
Not in 2.065<br>
2.066  will introduce "virtual" keyword<br>
2.067+ will change the defaults if it will still be considered good idea<br>
</blockquote>
<br>
What's the point of having "virtual" if the default doesn't change?<br>
<br>
Bye,<br>
bearophile<br>
</blockquote>
<br></div></div>
frequently mentioned example:<br>
<br>
class Something<br>
{<br>
    final: // want all to be final by default<br>
<br>
    // ...<br>
<br>
    virtual void foo() {} // but this one function<br>
}<br>
<br>
I think just keeping "virtual" but not changing defaults is a good practical compromise.<br>
</blockquote></div><br></div><div class="gmail_extra">I'm really trying to keep my lid on here...</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'll just remind that in regard to this particular point which sounds reasonable, it's easy to forgot that *all library code where the author didn't care* is now unusable by anybody who does. The converse would not be true if the situation was reversed.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">virtual-by-default is incompatible with optimisation, and it's reliable to assume that anybody who doesn't explicitly care about this will stick with the default, which means many potentially useful libraries may be eliminated for use by many customers.</div>
<div class="gmail_extra">Also, as discussed at length, revoking virtual from a function is a breaking change, adding virtual is not. Which means that, instead of making a controlled breaking change with a clear migration path here and now, we are committing every single instance of any user's intent to 'optimise' their libraries (by finalising unnecessarily virtuals) to breaking changes in their ABI - which *will* occur, since virtual is the default.</div>
<div class="gmail_extra">According to semantic versioning, this requires bumping the major version number... that's horrible!</div><div class="gmail_extra"><br></div><div class="gmail_extra">What's better; implementing a controlled deprecation path now, or leaving it up to any project that ever uses the 'class' keyword to eventually confront breaking changes in their API when they encounter a performance oriented customer?</div>
</div>