Le 06/11/2012 20:47, Manu a écrit :
> I actually quite liked Tristan's argument.
>
> [attr, attr2] feels more like what it is, an annotation. It does
> nothing, has no effect on the declaration on its own.
> the @attr syntax looks like existing attributes, and with that kinda
> comes the presumption that they actually DO something, affect the code
> generated in some way.

This is definitively what they should do at some point.

> For that reason, I buy the argument that [attrs...] being visually
> distinct makes more sense, more like what it is.
>
> Perhaps it should be termed 'annotation' rather than 'attribute'?
>
>
> On 6 November 2012 21:38, ponce <spam@spam.org <mailto:spam@spam.org>>
> wrote:
>
>     I like @(ArgumentList) better for stated reason: it looks like
>     existing @attributes.
>
>

Le 06/11/2012 20:46, David Nadlinger a écrit :
> On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
>> [ ArgumentList ]
>>
>> Pros:
>> precedent with C#
>
> I guess »precedent with Java« should be added to the respective @() list
> then.
>
> David

And python. By themselves, they represent a much bigger user base than C#

On 2012-11-06 20:52, Manu wrote:
> I'd like to re-enforce the consideration that @attribute() makes it
> looks like they affect the code generation somehow... they're really
> just annotations.

Then we just have to make it possible to generate code with these attributes :)

-- 
/Jacob Carlborg

On 6 November 2012 22:01, Jacob Carlborg <doob@me.com> wrote:

> On 2012-11-06 20:52, Manu wrote:
>
>> I'd like to re-enforce the consideration that @attribute() makes it looks like they affect the code generation somehow... they're really just annotations.
>>
>
> I still like the syntax.


I liked it initially too, but reason changed my mind...

On Tuesday, 6 November 2012 at 20:13:32 UTC, Manu wrote:
> this is a really good point. they are a tuple, you can slice it, iterate
> it...
> further supports [] to my mind ;)

Not really – [] represents an array, not a tuple.

David

Le 06/11/2012 21:17, Jacob Carlborg a écrit :
> On 2012-11-06 20:52, Manu wrote:
>> I'd like to re-enforce the consideration that @attribute() makes it
>> looks like they affect the code generation somehow... they're really
>> just annotations.
>
> Then we just have to make it possible to generate code with these
> attributes :)
>

That seems the most reasonable option.

On Tuesday, 6 November 2012 at 19:52:45 UTC, Manu wrote:
> I'd like to re-enforce the consideration that @attribute() makes it looks
> like they affect the code generation somehow... they're really just
> annotations.

Why would @ look like that to you? Actually, @ seems to yell »annotation« to me, probably because of my (limited) exposure to Python.

And don't forget that UDAs _do_ in practice have an effect on code generation, at least a lot more than @safe-ty attributes. Whether the mechanism by which they gain that effect is built into the compiler or implemented in a library doesn't matter to the user of a library.

David

On 11/06/2012 02:18 PM, Walter Bright wrote:
> For User Defined Attributes.
>
> In the north corner we have the current champeeeeon:
>
> -------
> [ ArgumentList ]
>
> Pros:
>      precedent with C#
>      looks nice
>
> Cons:
>      not so greppable
>      parsing ambiguity with [array literal].func();
>
> ------
> In the south corner, there's the chaaaaallenger:
>
> @( ArgumentList )
>
> Pros:
>      looks like existing @attribute syntax
>      no parsing problems
>
> Cons:
>      not as nice looking
> ------
>
> No hitting below the belt! Let the games begin!

One more vote for @( ArgumentList ) with optional () for simple ones - they seem like they would fit with the rest of the language much more nicely

@( ArgumentList ) is the winner for me.


On 2012-11-06 13:18, Walter Bright wrote:
> For User Defined Attributes.
>
> In the north corner we have the current champeeeeon:
>
> -------
> [ ArgumentList ]
>
> Pros:
> precedent with C#
> looks nice
>
> Cons:
> not so greppable
> parsing ambiguity with [array literal].func();
>
> ------
> In the south corner, there's the chaaaaallenger:
>
> @( ArgumentList )
>
> Pros:
> looks like existing @attribute syntax
> no parsing problems
>
> Cons:
> not as nice looking
> ------
>
> No hitting below the belt! Let the games begin!

I vote for @(ArgumentList).

Or @Arg1 @Arg2 ... as somebody mentioned.

It's more consistent with existing @-syntax.  Reusing [] is bad because it visually conflicts with array literals (and makes parsing harder to boot). @ is a unique symbol that, so far, is associated with attributes, so it makes sense to use it also to mark user-defined attributes.

I don't buy the argument that other languages have a different syntax. We're talking about D here, and what is chosen should make sense in the context of D, without undue influence from other languages.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher