Proposal: Definition of @-attributes

[Lars T. Kyllingstad]

Leandro Lucarella wrote:
> Lars T. Kyllingstad, el 28 de enero a las 09:46 me escribiste:
>> 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.
>>
>> 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
>>
>> 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 is! Even more, a big reason for introducing @attributes was to be able
> to make them user-defined.

I may be wrong, but somehow I got the impression that the important 
thing for Walter & co. was to have a new namespace for attributes, to 
avoid introducing a bunch of new keywords.  Then it makes no sense to 
use the same namespace for user-defined annotations, as adding new 
attributes later will be no better than adding keywords -- it will 
restrict or clash with user-defined annotations.


> I don't like your proposal mostly because of this point (but because is as
> arbitrary as the current regime, it only adds a mnemonic rule to remember
> where to put the @).

To a certain degree I agree with the latter.  It was just the most 
definite rule I could come up with that includes @safe, @unsafe, etc. 
but not private, public, etc.  Also it doesn't increase the keyword 
count -- sure, 'property' and 'disable' become keywords, but 'pure' and 
'nothrow' become annotations.


> I think all D attributes should have the @, if you have a bunch of them,
> maybe there should be a way to group them, like:
> 
>      @(safe nothrow private property) int foo() { ... }
> 
> But I'm not sure that adds anything to readability. I don't think this is
> a huge problem, since as somebody already pointed out, you can always
> group declarations with the same attributes together and type the
> attribute just once (this is not Java :).

That doesn't look too bad, but if *all* attributes are in the 
@-namespace, then we *really* should keep user-defined annotations out 
of it.

-Lars