On 4 June 2013 03:06, David Nadlinger <code@klickverbot.at> 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.

Ah, sorry, I didn't realise that. I only recall conversations arising when it actually became deprecated, and people had to change their code.

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.

The exact same path is available if you want to apply it:
 1. Introduce 'virtual', create a warning when override is used on a function not marked. Functions remain virtual-by-default for the time being.
 2. At some later time, deprecate it (collecting the stragglers who haven't updated their code yet). Functions remain virtual-by-default.
 3. Pull the pin. Functions become final by default, and virtuals should have already been marked during the previous periods.

I'm not sure I follow your point about an isolated base class.
In the event you have an isolated base class, where no classes are derived from it, then it's not actually polymorphic, so why should it's methods be virtual?
In the event that it's a base-class-in-waiting, then it's true that you'll notice a compile error at a later time when you do eventually derive from it, but that's not really a breaking change, and it's almost in line with my points about explicit consideration; each method that receives the virtual keyword would take a moments consideration from the author as to whether it's actually correct/safe to be overriding that method or not. Ie, the momentary compile error where you write 'virtual' gives you the opportunity for that thought.

>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!

But this is a practical solution. The only counter-proposal I've heard is Andrei's 'all methods use ufcs' idea, but I think that one would be a much harder sell to the community. I'm certainly not convinced.

It's really quite trivial, it's orthogonal with usage of override, it's more efficient, less error prone (which I have demonstrated happen all the time), enhances interoperation with C++, and it should even improve code fragility too (ie, people possibly overriding methods that are unsafe to override where the author never considered the possibility).

Is there a reason this change offends you enough to call me names? Or can you at least tell how I'm being narrow-minded?

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?

That's not quite the case though. Even if I could retrain internal staff to start doing that everywhere, you've potentially blocked access to a whole bunch of libraries because library authors don't follow our style guide.
We suffer this in C++ all the time (see my many rant's about unnecessarily spending my life re-inventing wheels). Anything to make subtle pushes that improve usability/portability of libraries can only be a good thing. Especially when library authors generally don't specifically consider all usage environments. The language can assist some some extent.

It's also precisely the same amount of work to type 'virtual:' (and it's the lesser common case to want to), except taking that angle enables the advantages I mention above, and also tends to force people to give a moments consideration to their API design/intent wrt virtual.
Remember going virtual is a one-way trip. It can never be undone, which makes it a terribly dangerous default state.

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