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!

On Tuesday, 6 November 2012 at 19:18:39 UTC, Walter Bright wrote:
> @( ArgumentList )
>     not as nice looking

Actually, I find it even nicer looking than the other syntax. Combine it with allowing the omission of the parens for a single argument and allowing multiple specifications of it per declaration, and it starts to look a whole lot like the built-in attributes.

David

Le 06/11/2012 20:18, Walter Bright a écrit :
> 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
>

Look like what is done in Java, python and PHP.

> Cons:
> not as nice looking
> ------
>
> No hitting below the belt! Let the games begin!

BTW, I'm all for @argument @argument @argument rather than @(argumentlist)

@( ArgumentList ) FTW :D

On Tuesday, 6 November 2012 at 19:18:39 UTC, 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!

Am 06.11.2012 20:18, schrieb Walter Bright:
> 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 think @( ArgumentList ) would be more consistent with what D already has, but my vot still goes for [ ArgumentList ] because personally I find that @'s make the code look "ugly". There are other languages where the '@' is only used for language features you shouldn't be using a lot.

Kind Regards
Benjamin Thaut

I like @(ArgumentList) better for stated reason: it looks like
existing @attributes.

On 2012-11-06, 20: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!

@( ArgumentList ).

-- 
Simen

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

On 2012-11-06 20: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 ). If this is syntax chosen I also hope @attribute will be legal as well.

-- 
/Jacob Carlborg

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

> I like @(ArgumentList) better for stated reason: it looks like
> existing @attributes.
>