Why the @ in @safe? & UDAs

[eles]

On Thursday, 7 November 2013 at 09:29:39 UTC, Daniel Kozak wrote:
> On Thursday, 7 November 2013 at 08:11:53 UTC, WasThere wrote:
>> Anyway adding or removing @ will cause code breakage,
>> but leaving @ for UDAs it's better. It will be beautiful in 
>> words of consistency.
>
> Yes, but removing @ from @safe and others will mean more new 
> keywords, so now I can have string system = "Linux" and bool 
> safe = true.... But with adding @ to nothrow and others it will 
> just break code use this keywords

This is important.
I think the least painful path to achieve both consistency and 
minimum brakage would be to introduce different prefixes for 
built-in attributes and for user-defined attributes, for example:

#private
@myattr

This still let open the question of a different kind of grouping 
attributes (eg wrt their influence on mangling) but the latter, 
at least concerning the ABI, should be less a concern for the 
developer, but for the implementor.

OTOH, there is some way of distinguishing between UDA and 
non-UDA: their qualification name. Maybe this could be extended 
some way (eg prefix all attributes with @, but someway give them 
names with categories):

@abi!nogc

Yes, it's a bit ugly.

Finally, one suggestion about those long chains of "pure @safe 
nothrow"

Could mega-attributes be defined?

alias myAttr=(pure @safe nothrow);

myAttr myFunction() {}

?

Some might even be pre-defined in std so that could be part of 
the standard.

PS public, private and so on have strong C++ history where they 
are written without @ and this may introduce a bias in our view.