Broken?

[Sean Kelly]

On Wednesday, 12 March 2014 at 17:08:59 UTC, Andrei Alexandrescu
wrote:
> On 3/12/14, 10:05 AM, monarch_dodra wrote:
>> On Wednesday, 12 March 2014 at 16:46:26 UTC, Andrei 
>> Alexandrescu wrote:
>>> On 3/12/14, 4:40 AM, Manu wrote:
>>>> Thank you.
>>>> There you go, it's not even hypothetical.
>>>
>>> I think the example given works against your argument.
>>>
>>> Andrei
>>
>> How so? The example was his argument verbatim.
>
> His argument assumed at core that the library designer knows 
> better than the library user what the customization points are, 
> and that most functions are virtual by mistake.

And this argument is absolutely correct, in my experience.  By
making virtuality an explicit choice, the library designer is
specifying that a given function is a part of the published
interface for a class and overriding it has some explicit purpose
that will be maintained over time.

In a "virtual by default" world, there is no explicit contract
regarding the virtuality of functions, and so the library writer
may not feel any obligation to retain those functions at all,
their signatures, or their application to the operation of the
class.  Unless a particular function is documented as
overridable, you can't assume that the library writer didn't
simply forget to mark it final.  Doing otherwise puts the library
writer in an awkward position by imposing an obligation to
preserve behavior that was never intended to be public in the
first place.  The example provided demonstrated this exact
problem.