Final by default?

Manu turkeyman at gmail.com
Sun Mar 16 07:24:05 PDT 2014


On 16 March 2014 21:28, Rainer Schuetze <r.sagitario at gmx.de> wrote:

>
>
> 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();
>

I frequently find myself needing something like this. What's wrong with
aliasing attributes directly?
DGC/LDC offer their own internal attributes, but you can't make use of them
and remain portable without an ability to do something like the #define
hack in C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140317/fb29aa6d/attachment.html>


More information about the Digitalmars-d mailing list