Proposal: Definition of @-attributes

Don nospam at nospam.com
Thu Jan 28 05:28:18 PST 2010


Lars T. Kyllingstad wrote:
> Currently, there doesn't seem to be any clear definition of which 
> attributes should be prefixed with @ and which shouldn't.

[snip]

> Solution (?):
> I therefore propose the following definition of @-namespace attributes:
> 
>     The @-attributes of a function only place compile-time
>     constraints on the body of that function.
> 
> Specifically, this means that the @-attributes of a function do not 
> place constraints on calling code, change the syntax of calling code, 
> nor change the visibility of the function.
> 
> The above definition means that the following will be @-attributes:
> 
>     @safe, @trusted, @unsafe
>     @nothrow, @pure

@unsafe places constraints on calling code: it can't be @safe.

> The following, on the other hand, will be normal keywords:
> 
>     private, protected, public
>     deprecated, disable
>     property
> 
> I realise that a major problem with the proposal is that it severely 
> limits the possibility of later having user-defined annotations in the 
> @-namespace as well.  But I am not convinced this is a good idea anyway.

It's hard to come up with a definition which lets private, protected, 
public remain as keywords. It seems to be almost impossible to come up 
with a definition which keeps @property as an annotation.

The simple rule of thumb, "a program which compiles, should still work 
if all of the annotations are removed" (obviously, excluding 
metaprogramming code which is checking for annotations) comes close, but 
fails miserably at @property.



More information about the Digitalmars-d mailing list