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 muchwhich was gladly accepted recently. […] how did the override
smaller number than the breakage
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.
>From DConf I know that you are actually are a friendly, reasonable person, but in this discussion, you really come across as a narrow-minded zealot to me. So, please, let's focus on finding an actually practical solution!
For example, if we had !pure/!nothrow/!final or something along the lines, just mandate that "final:" is put at the top of everything in your style guide (easily machine-enforceable too) – problem solved?
And maybe it would even catch on in the whole D community and lead to a language change in D3 or a future iteration of the language.
David