Final by default?

[Andrei Alexandrescu]

On 3/14/14, 8:30 AM, Namespace wrote:
> On Friday, 14 March 2014 at 15:17:08 UTC, Andrei Alexandrescu wrote:
>> 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
>
> Yeah. My idea is popular.

Apologies for not having seen it!

Andrei