On 4 June 2013 02:59, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

On 6/3/13 12:25 PM, Manu wrote:

You won't break every single method, they already went through that
recently when override was made a requirement.
It will only break the base declarations, which are far less numerous.

That's what I meant.

How can you justify the change to 'override' with a position like that?
We have already discussed that we know PRECISELY the magnitude of
breakage that will occur.
It is: magnitude_of_breakage_from_override /
total_number_of_derived_classes. A much smaller number than the breakage
which was gladly accepted recently.

Well it's kinda too much relativism that the number of breakages is considered small because it's smaller than another number.

And the matter is far from trivial.

It is trivial. To paraphrase a classic: "I'm not taking away your ability to make everything final, you can type 'final:' as much as you like."

You read my posts where I illustrate how going virtual is a one-way ride right?

You can safely change to virtual, but you can't go from virtual back to final.

Aside from the performance hazards, and the empirical evidence from watching C++ programmers use D, virtual-by-default has the dangerous potential to lock you in to an awkward situation where you can never safely make a change to fix something that should never have been that way in the first place.

In fact, if you think this is
trivial, then how did the override change ever get accepted? That is
most certainly trivial by contrast, and far more catastrophic in terms
of breakage.

That's a completely different issue, so this part of the argument can be considered destroyed.

Rubbish. A similar set of considerations apply, and there's an awful lot more supporting this one in addition.