Final by default?

Rainer Schuetze r.sagitario at gmx.de
Sun Mar 16 04:28:24 PDT 2014



On 14.03.2014 23:25, deadalnix wrote:
> On Friday, 14 March 2014 at 22:06:13 UTC, Daniel Kozák wrote:
>> 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.
>>
>
> If I may, final!false . We have a syntax for compile time
> parameter. Let's be consistent for once.
>
> The concept is solid and is the way to go. DIP anyone ?

To me, it's not a decision "final or virtual", but "final, virtual or 
override", so a boolean doesn't work. final!false could infer "virtual 
or override", but then it would loose the explicitness of introducing or 
overriding virtual.

I'm in favor of adding the keyword "virtual", it is known by many from 
other languages with the identical meaning. Using anything else feels 
like having to invent something different because of being opposed to it 
at the start.

Adding compile time evaluation of function attributes is still worth 
considering, but I'd like a more generic approach, perhaps something 
along a mixin functionality:

enum WINAPI = "export extern(Windows)";

@functionAttributes!WINAPI HANDLE GetCurrentProcess();

though I would prefer avoiding string mixins, maybe by providing a 
function type as prototype:

alias export extern(Windows) void function() fnWINAPI;

@functionAttributesOf!fnWINAPI HANDLE GetCurrentProcess();


More information about the Digitalmars-d mailing list