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 have no horse in the final race but I would say be wary of
becoming too conservative because a client over reacts to a
regression. Their reaction sounds unreasonable, especially given
how quickly the issue was addressed. Where did the narrative that
it was a deliberate breaking change come from?
