On 4 June 2013 02:59, Andrei Alexandrescu <seewebsiteforem...@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.