On 16 March 2014 21:28, Rainer Schuetze <[email protected]> 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.
