Final by default?

[Don]

On Thursday, 13 March 2014 at 05:15:58 UTC, Sean Kelly wrote:
> 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.

And std.json is among the worst code I've ever seen. I'm a bit 
shocked that anyone would be using it in production code.

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

I agree completely.

Some things that really should be fixed, don't get fixed because 
of a paranoid fear of breaking code. And this tends to happen 
with the issues that can give nice warning messages and are easy 
to fix...

Yet there are still enough bugs that your code breaks every 
release anyway.
We need to lose the fantasy that there is legacy code which still 
compiles.
Anything more than a year or so old is broken already.

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