Final by default?

[Chris Williams]

On Wednesday, 12 March 2014 at 22:50:00 UTC, Walter Bright wrote:
> But we nearly lost a major client over it.
>
> We're past the point where we can break everyone's code.

As someone who would like to be able to use D as a language, 
professionally, it's more important to me that D gain future 
clients than that it maintains the ones that it has. Even more 
important is that it does both of those things.

The JSON implementation, for example, is fine if you just want to 
read JSON data and if you are willing to look at the std.json.d 
file to figure out what the data structures look like, so you can 
actually interact with them. The whole thing should be replaced, 
because JSON is a fairly big part of modern life, and not having 
a very usable library for it is the sort of thing that would 
prevent someone from considering the language for a project.

To some extent, making changes that are non-breaking is good. But 
I don't think that's a full solution. Some of the features of the 
language just aren't where they need to be to encourage mass 
adoption, and fixing those will be breaking.

Sooner or later it's going to be necessary to either branch and 
support old versions of the compiler and the library, and/or to 
provide compatability flags. Flags like "--strict" are fairly 
common, so having a compiler mode that defaults to final 
declarations, defaults to nothrow, pure, safe, etc. seems pretty 
reasonable. You could even make that the default mode, with 
"--nonstrict" or something as a compiler flag preserving 
backwards compatability (eternally, or for a given period of 
time). Alternately, one could do like Java and have target 
versions for compiling. If you did that, you would probably want 
to lump breaking changes into a single release every few years, 
so that there isn't a different version number for every update.

I like the idea of having final: and !final:, but I think that 
compiler flags are the right answer for how to approach 
defaulting final.