View mode: basic / threaded / horizontal-split · Log in · Help
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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.
>
>
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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#
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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...
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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.
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
@( 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!
November 06, 2012
Re: [ ArgumentList ] vs. @( ArgumentList )
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
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home