Final by default?

[Steven Schveighoffer]

On Thu, 13 Mar 2014 04:43:51 -0400, Don <x at nospam.com> wrote:

> On Thursday, 13 March 2014 at 06:02:27 UTC, Walter Bright wrote:
>> On 3/12/2014 9:23 PM, Manu wrote:
>>> It's not minor, and it's not achievable by other means though.
>>
>>     class C { final: ... }
>>
>> does it.
>>
>>
>>> You and Andrei are the only resistance in this thread so far. Why  
>>> don't you ask
>>> 'temperamental client' what their opinion is? Give them a heads up,  
>>> perhaps
>>> they'll be more reasonable than you anticipate?
>>
>> I didn't even know about this client before the breakage. D has a lot  
>> of users who we don't know about.
>>
>>> Both myself and Don have stated on behalf of industrial clients that  
>>> we embrace
>>> breaking changes that move the language forward, or correct clearly  
>>> identifiable
>>> mistakes.
>>
>> Breaking changes has been a huge barrier to Don's company being able to  
>> move from D1 to D2. I still support D1 specifically for Don's company.
>
> Yes, but the problem is not the changes which cause compile errors and  
> force you to change your code in obvious ways. The problem is subtle  
> changes to behaviour.
>
> The worst breaking change in D2, by far, is the prevention of array  
> stomping.
>
> After that change, our code still runs, and produces exactly the same  
> results, but it is so slow that it's completely unusable. This one of  
> the main reasons we're still using D1.

What is your use case(s), might I ask? Prevention of array stomping, I  
thought, had a net positive effect on performance, because it no longer  
has to lock the GC for thread-local appends.

-Steve