Broken?

[Andrei Alexandrescu]

On 3/11/14, 8:04 PM, Manu wrote:
> I'm really trying to keep my lid on here...

Yep, here we go again :o).

> 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.

There's an asymmetry introduced by the fact there's today code in use.

> 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.

Virtual by default is, however, compatible with customization and 
flexibility.

Unstated assumption: "many potential useful libraries" assumes many 
libraries use traditional OO design in their core components.

Unstated assumption: "many customers".

> Also, as discussed at length, revoking virtual from a function is a
> breaking change, adding virtual is not.

Changing the default is a breaking change.

> 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.

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.

> According to semantic versioning, this requires bumping the major
> version number... that's horrible!

Appeal to emotion.

> 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?

It's better to leave things be. All I see is the same anecdote gets 
vividly told again whenever the topic comes up.


Andrei