Final by default?

Daniel Murphy yebbliesnospam at gmail.com
Fri Mar 14 08:43:40 PDT 2014


"Andrei Alexandrescu"  wrote in message 
news:lfv6hk$12su$1 at digitalmars.com...

> A few possibilities discussed around here:
>
> !final
> ~final
> final(false)

None of those are as nice as 'virtual'.  It's not like it's a common 
variable name.

> @disable final

Nope, already valid.

> 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.

This is a much bigger change than adding a new storage class, both from the 
language and implementation perspectives.  How often do you really need this 
much power, now that we have attribute inference? 



More information about the Digitalmars-d mailing list