Final by default?

[Don]

>> 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.
>
> Backward compatibility is more like a spectrum than a 
> threshold. Not having it now is not an argument to cease 
> pursuing it.

Exactly, it's a spectrum. But at any given time, the whole 
language and library are not at a single point on the spectrum. 
Some things are frozen, others in practice are not. And the 
problem is that D has historically acted as if everything was the 
same, which just doesn't work.

I think three levels of forwards compatibility are useful to 
consider:

1. Frozen. Things that you can absolutely rely on, we will NEVER 
change it under any circumstances. Any bugs in the design will 
never be fixed.

2. Stable. We will attempt to minimize changes, but we don't 
guarantee your code will never break. (It may break in order to 
prevent breakage of things in case 1, for example). We can 
guarantee a deprecation path in most cases.

3. We will avoid gratuitous changes, but it will almost certainly 
change in the future.

And what we want to do, is gradually move as many things as we 
can from category (2) into category (1), and from (3) into (2).

I'd like to see us giving a lot more guarantees, rather than 
trying to keep promises we never actually made.