Final by default?

[Sean Kelly]

On Wednesday, 12 March 2014 at 22:50:00 UTC, Walter Bright wrote:
> The argument for final by default, as eloquently expressed by 
> Manu, is a good one. Even Andrei agrees with it (!).
>
> The trouble, however, was illuminated most recently by the 
> std.json regression that broke existing code. The breakage 
> wasn't even intentional; it was a mistake. The user fix was 
> also simple, just a tweak here and there to user code, and the 
> compiler pointed out where each change needed to be made.
>
> But we nearly lost a major client over it.

I find this a bit baffling.  Given the investment this customer 
must have in D, I can't imagine them switching to a new language 
over something like this.  I hate to say it, but this sounds like 
the instances you hear of when people call up customer service 
just to have someone to yell at.  Not that the code breakage is 
okay, but I do feel like this may be somewhat of an exaggeration.

Regarding this virtual by default issue.  I entirely support 
Manu's argument and wholeheartedly agree with it.  I even think 
that I'd be more likely to use D professionally if D worked this 
way, for many of the same reasons Manu has expressed.  There may 
even be a window for doing this, but the communication around the 
change would have to be perfect.

Regarding user retention... I've spent the past N months 
beginning the process of selling D at work.  The language and 
library are at a point of maturity where I think it might have a 
chance when evaluated simply on the merits of the language 
itself.  However, what has me really hesitant to put my shoulder 
behind D and really push isn't that changes occur sometimes.  
Even big changes.  It's how they're handled.  Issues come up in 
the newsgroup and are discussed back and forth for ages.  
Seriously considered.  And then maybe a decision is apparently 
reached (as with this virtual by default thing) and so I expect 
that action will be taken.  And then nothing happens.  And other 
times big changes occur with seemingly little warning.  
Personally, I don't really require perfect compatibility between 
released, but I do want to see things moving decisively in a 
clearly communicated direction.  I want to know where we're going 
and how we're going to get there, and if that means that I have 
to hold on moving to a new compiler release for a while while I 
sort out changes that's fine.  But I want to be able to prepare 
for it.  As things stand, I'm worried that if I got a team to 
move to D we'd have stuff breaking unexpectedly and I'd end up 
feeling like an ass for recommending it.  I guess that's probably 
what prompted the "almost lost a major client" issue you 
mentioned above.  This JSON parser change was more the proverbial 
straw than a major issue in itself.

As for the !virtual idea... I hate it.  Please don't add yet more 
ways for people to make their code confusing.