Final by default?

[Daniel Kozák]

Andrei Alexandrescu píše v Pá 14. 03. 2014 v 08:17 -0700:
> On 3/14/14, 4:37 AM, Daniel Murphy wrote:
> > "Walter Bright"  wrote in message news:lfu74a$8cr$1 at digitalmars.com...
> >
> >> > No, it doesn't, because it is not usable if C introduces any virtual
> >> > methods.
> >>
> >> That's what the !final storage class is for.
> >
> > My mistake, I forgot you'd said you were in favor of this.  Being able
> > to 'escape' final certainly gets us most of the way there.
> >
> > !final is really rather hideous though.
> 
> A few possibilities discussed around here:
> 
> !final
> ~final
> final(false)
> @disable final
> 
> I've had an epiphany literally a few seconds ago that "final(false)" has 
> the advantage of being generalizable to "final(bool)" taking any 
> CTFE-able Boolean.
> 
> On occasion I needed a computed qualifier (I think there's code in 
> Phobos like that) and the only way I could do it was through ugly code 
> duplication or odd mixin-generated code. Allowing computed 
> qualifiers/attributes would be a very elegant and general approach, and 
> plays beautifully into the strength of D and our current investment in 
> Boolean compile-time predicates.
> 
> 
> Andrei
> 

First I think have something like 

@disable(final,nothrow) would be the best way, but than I think about it
and realize that final(false) is much more better.

Only advantege of @disable(all) or @disable(something, something_else)
is we can disable more things more easily. But I almost never have
needed this.