Final by default?

[Jesse Phillips]

On Wednesday, 12 March 2014 at 22:50:00 UTC, Walter Bright wrote:
> We're past the point where we can break everyone's code. It's 
> going to cost us far, far more than we'll gain. (And you all 
> know that if we could do massive do-overs, I'd get rid of put's 
> auto-decode.)

I figure I'll throw in my thoughts (not to convince you of what 
is right). I don't have a bread and butter program in D, mainly 
just hobby.

I don't agree with the choice behind making this flop. I was 
surprised to find out that the final-by-default had been approved 
to begin with, you were already aware of the desire to not "break 
everyone's code," pushing for it throughout discussions. But 
eventually something made you change your mind, and now a very 
different situation made you change it back.

D2 shouldn't be arbitrarily frozen like was done with D1. There 
are things which need to be done and things which should be done, 
some of which aren't even known yet. It doesn't sound like the 
intention is to go this far, so I'm hoping this is common ground 
that some of this stuff will break a lot of code. But we are 
scared because D1 got the "stable" treatment and that meant 
things remained broken.

D has had a history of random breaking changes (great work on 
killing most regressions before release), but planned/expected 
breaking changes still don't get the upgrade path they deserve. 
Daniele said it best, the code should compile with the current 
release and the next release, or more. Meaning old code complies 
with the new compiler, and changes to remove the use of 
deprecation should compile with the older compiler. (This allows 
local builds to update code for a new compiler while the 
automated builds continue to build the same code with older 
compiler)

If we can do this, and even extend it out for longer than "next" 
release we're providing a good upgrade path. This will likely 
lead to pleasing the majority of users that need require 
stability, even if the change doesn't appear to be worth it (the 
current final-by-default may not be worth it from a breaking code 
point of view, but seems to be considered the "right thing").

> So, there's the solution that has been proposed before:
>
>    !final
>    !pure
>    !nothrow
>    etc.

I think this is ok, I'm also ok with the introduction of new 
keywords, preferably not, not_nothrow. !nothrow isn't great, but 
oh well.