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.
