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

Reply via email to