Final by default?

[Dejan Lekic]

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