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.

I'd also suggest the convention that @-attributes are written after the function signature, while other attributes are written before:

    private property int foo()  @safe @nothrow { ... }

Comments?

-Lars

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.

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.

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

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

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------

Don wrote:
> 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.

I considered that, but I think of it the other way around: It's @safe that places the "can't call @unsafe" constraint, and not @unsafe that places a "can't be called by @safe" constraint.

But I agree there's a fair bit of arbitrariness in this as well. :)

-Lars

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

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:

To me attributes can make the code look uglier and, as pointed out, there there really is no clear seperation.

So in my opinion, to keep the code looking clean attributes should only include those for the function, not its parameters. This prevents in, out, ref, const, etc. and allows for @safe, @property, etc.

If a delegate is a parameter than attributes would of course be ok in the parameter since they apply to a function.

Lars T. Kyllingstad, el 28 de enero a las 15:38 me escribiste:
> >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.

I don't know, maybe you're right.

(thinking out loud, what's next can be a load of crap, be warned :)

User defined annotation can have namespaces though:
import foo;

@foo.bar f() {
	// ...
}

But if foo gets introduced in the future as a language feature, you're doom. Maybe attributes should be always "imported" and be subject to lookup rules just like regular funcions?

static import std.attr; // standard
import std.safe: trusted; // standard
import foo: public; // non-standard

@std.attr.nothrow @trusted @public f();


It is a radical change, so I don't expect it to be in D2 of course.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------

Jesse Phillips, el 28 de enero a las 15:39 me escribiste:
> 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:
> 
> To me attributes can make the code look uglier and, as pointed out, there there really is no clear seperation.
> 
> So in my opinion, to keep the code looking clean attributes should only include those for the function, not its parameters. This prevents in, out, ref, const, etc. and allows for @safe, @property, etc.

D attributes[1] can't be part of parameters. That are InOut "modifiers" or storage classes[2] (there are some overlapping between the two, for example the keyword const is a storage class *and* an attribute, that can be the cause of confusion).

[1] http://www.digitalmars.com/d/2.0/attribute.html
[2] http://www.digitalmars.com/d/2.0/declaration.html

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------

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() { ... }

I'm not saying D should do this, but in my opinion placing those things before function name and return type isn't very readable once you get more than two modifiers, regardless of whether you use @ or not. Compare:

int foo() safe nothrow private property { ... }

This is especially true if you have user-defined attributes, because you no longer have to think about where is return type name and where is the attribute. The method signature is visually separated by the parenthesis:

SomeType foo() private somethingable { ... }
vs
@somethingable private SomeType foo() { ... }