On Wednesday, 12 March 2014 at 11:40:39 UTC, Manu wrote:
On 12 March 2014 20:40, monarch_dodra <[email protected]>
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.
It can also happen the other way if I mark a method virtual that
used to be final, which was overloaded in a subclass, right?
--
Paulo
