On Wednesday, 12 March 2014 at 22:50:00 UTC, Walter Bright wrote:
The argument for final by default, as eloquently expressed by
Manu, is a good one. Even Andrei agrees with it (!).
The trouble, however, was illuminated most recently by the
std.json regression that broke existing code. The breakage
wasn't even intentional; it was a mistake. The user fix was
also simple, just a tweak here and there to user code, and the
compiler pointed out where each change needed to be made.
But we nearly lost a major client over it.
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.)
Instead, one can write:
class C { final: ... }
as a pattern, and everything in the class will be final. That
leaves the "but what if I want a single virtual function?"
There needs to be a way to locally turn off 'final'. Adding
'virtual' is one way to do that, but:
1. there are other attributes we might wish to turn off, like
'pure' and 'nothrow'.
2. it seems excessive to dedicate a keyword just for that.
So, there's the solution that has been proposed before:
!final
!pure
!nothrow
etc.
I am still not convinced about final-by-default. However,
discussions here have proven that in many cases people would
benefit from it.
So, how about we make a next major release branch, 2.1, appoint
some 2.1 maintainers (Manu for an example, as he is one of the
major forces behind this movement). These individuals will filter
and merge changes in the 2.0 branch into the 2.1.
This will nicely allow companies to have a transition period from
2.0.x to 2.1.x at the time of convenience.
Kind regards
