On 12 March 2014 20:40, monarch_dodra <monarchdo...@gmail.com> wrote:
> On Wednesday, 12 March 2014 at 03:05:00 UTC, Manu wrote: > >> I'm really trying to keep my lid on here... >> >> 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. >> >> 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. >> 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. >> According to semantic versioning, this requires bumping the major version >> number... that's horrible! >> >> 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? >> > > Case in point: > https://github.com/D-Programming-Language/phobos/pull/1771 > "mark std.zip classes as final" > > Long story short: MartinNowak decided to make the Zip classes final, since > it made no sense to have any of the functions virtual, or to have anybody > derive from them anyways. > > https://github.com/D-Programming-Language/phobos/pull/1771#issuecomment- > 36524041 > Comment from Dav1dde: > "Just to let you know, it broke my code" > Thank you. There you go, it's not even hypothetical.
