<div dir="ltr">On 4 June 2013 03:06, David Nadlinger <span dir="ltr"><<a href="mailto:code@klickverbot.at" target="_blank">code@klickverbot.at</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Monday, 3 June 2013 at 16:25:24 UTC, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You won't break every single method, they already went through that recently when override was made a requirement. […] A much<div class="im"><br>
smaller number than the breakage<br></div>
which was gladly accepted recently. […] how did the override<br>
change ever get accepted […]<br>
</blockquote>
<br>
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.<br>
<br>
According to <a href="http://dlang.org/changelog.html" target="_blank">http://dlang.org/changelog.<u></u>html</a>, 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.<br>
</blockquote><div><br></div><div style>Ah, sorry, I didn't realise that. I only recall conversations arising when it actually became deprecated, and people had to change their code.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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.<br>
</blockquote><div style><br></div><div style>The exact same path is available if you want to apply it:</div><div style> 1. Introduce 'virtual', create a warning when override is used on a function not marked. Functions remain virtual-by-default for the time being.</div>
<div style> 2. At some later time, deprecate it (collecting the stragglers who haven't updated their code yet). Functions remain virtual-by-default.</div><div style> 3. Pull the pin. Functions become final by default, and virtuals should have already been marked during the previous periods.</div>
<div><br></div><div style>I'm not sure I follow your point about an isolated base class.</div><div style>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?</div>
<div style>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.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>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!<br>
</blockquote><div><br></div><div style>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.</div>
<div style><br></div><div style>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).</div>
<div style><br></div><div style>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?</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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?</blockquote>
<div><br></div><div style>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.</div>
<div style>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.</div>
<div style><br></div><div style>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.</div>
<div style>Remember going virtual is a one-way trip. It can never be undone, which makes it a terribly dangerous default state.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 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.<span class="HOEnZb"><font color="#888888"><br>
<br>
David</font></span></blockquote></div></div></div>