Proposal: Definition of @-attributes

[Jason House]

Lars T. Kyllingstad Wrote:

> In the "Function calls" thread the question of "which attributes should 
> be in the @-namespace" has again come up.
> 
> 
> Problem:
> Currently, there doesn't seem to be any clear definition of which 
> attributes should be prefixed with @ and which shouldn't.  New 
> attributes get an @, while already existing attributes don't, and it all 
> seems a bit arbitrary.  Then again, we probably don't want *all* 
> attributes to be written with @, as that would just make code look messy:
> 
>      @safe @nothrow @private @property int foo() { ... }
> 
> 
> 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.

That kills the extensibility of attributes.  Users should be able to define attributes that are only used through reflection. It may be best to define a criteria for what constitutes a keyword.

 
> 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.

What you list as attributes does effect calling code when the calling code uses certain attributes...


> 
> The above definition means that the following will be @-attributes:
> 
>      @safe, @trusted, @unsafe
>      @nothrow, @pure
> 
> The following, on the other hand, will be normal keywords:
> 
>      private, protected, public
>      deprecated, disable
>      property


This division seems reasonable to me.

 
> 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.

Many of those that wanted @attributes in the first place wanted it because of its extensibility.