On 6/3/13 1:06 PM, David Nadlinger wrote:
On Monday, 3 June 2013 at 16:25:24 UTC, Manu wrote:
You won't break every single method, they already went through that
recently when override was made a requirement. […] A much
smaller number than the breakage
which was gladly accepted recently. […] how did the override
change ever get accepted […]
It appears as if either you have a interesting definition of "recently",
or you are deliberately misleading people by bringing up that point over
and over again.
According to http://dlang.org/changelog.html, omitting "override"
produced a warning since D 2.004, which was released back in September
2007! Granted, it was only actually turned from a deprecation warning
into an actual deprecation in 2.061 (if my memory serves me right), but
it's mostly a flaw in the handling of that particular deprecation that
it stayed at the first level for so long. The actual language change was
made – and user-visible – almost six (!) years ago, which is a lot on
the D time scale.
You are also ignoring the fact that in contrast to requiring "override",
there is no clean deprecation path for your proposal, at least as far as
I can see: Omitting the keyword started out as a warning, and IIRC still
is allowed when you enable deprecated features via the compiler switch.
How would a similar process look for virtual-by-default? As far as am
isolated module with only a base class is concerned, this is not
question of valid vs. invalid code, but a silent change in language
semantics.
[snip]
There's one more issue with the comparison that must be clarified (I
thought it was fairly obvious so I didn't make it explicit in my
previous note): override is not comparable because it improves code
correctness and maintainability, for which there is ample prior
evidence. It's also a matter for which, unlike virtual/final, there is
no reasonable recourse.
So invoking the cost of imposing explicit override vs imposing virtual
as an argument for the latter is fallacious.
Andrei
