Roman Ivanov Wrote:

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

I guess I didn't say what I wanted to say. IMO, Java syntax for such things is not the best one possible for readability. You have to scan the code very extensively to separate method signature from the surrounding fluff:

@FrameworkBinding(name="xyz")
@Retention(Whatever.RUNTIME)
public final static synchronized MyClass function(AnotherClass) throws SomeException{
//...
}

I would rather have something like this:

MyClass function(AnotherClass) public final static synchronized
throws[SomeException]
frameworkBinding[name="xyz"]
retention[Whatever.RUNTIME] {
//...
}

Why? Because you would know that the method signature is the first thing that starts after newlines. Also, using parenthesis for both method calls and annotations is visually confusing.

Again, I understand that what you're discussing here is not quire the same as annotations, and I don't ask that D adopts the syntax I'm posting, but IMO there is a lesson about readability that can be learned here and that should be kept in mind.

Ability to mentally and visually separate pieces of code with different functionality makes reading code _much_ simpler. So does the ability to "group" together the pieces of code that have similar functionality.

Leandro Lucarella Wrote:

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

If and when D gets user-defined attributes, they could have their own namespace:

@@foo
or maybe
#foo

(Is # used for anything at all in D right now?)

Maybe it's too ugly though, but then the current attribute syntax isn't a thing of beauty to begin with.

Clemens

Clemens:
> (Is # used for anything at all in D right now?)

It's not used, maybe because D tries to not use C syntax with a different semantics.
If this constraints get relaxed, then probably we can invent some useful way to use it. Do you have ideas?

Bye,
bearophile

On 01/29/2010 12:13 PM, bearophile wrote:
> Clemens:
>> (Is # used for anything at all in D right now?)
>
> It's not used, maybe because D tries to not use C syntax with a different semantics.
> If this constraints get relaxed, then probably we can invent some useful way to use it. Do you have ideas?
>
> Bye,
> bearophile

Oh it's used!

...for the #line declaration.

Fri, 29 Jan 2010 05:41:00 -0500, Clemens wrote:

> Leandro Lucarella Wrote:
> 
>> 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 :)
> 
> If and when D gets user-defined attributes, they could have their own namespace:
> 
> @@foo
> or maybe
> #foo
> 
> (Is # used for anything at all in D right now?)
> 
> Maybe it's too ugly though, but then the current attribute syntax isn't a thing of beauty to begin with.

I'm wondering. If I make a tool that parses D sources such as a documentation generator, can I define new annotations freely or are there any rules involved? I could really have use for e.g. unit testing annotations. The compiler should ignore them, however - preferably now and also in the future.