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
>
> Cons:
> not as nice looking
> ------
>
> No hitting below the belt! Let the games begin!

About @() vs @[] the key point to me is that this is consistent with tuple syntax (which don't exists yet \o/).

The important point to me is that @a is allowed.

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!

@() with required ().
So we will still have place for new language attributes like @rox etc ;)

Le 08/11/2012 00:14, nazriel a écrit :
> 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!
>
> @() with required ().
> So we will still have place for new language attributes like @rox etc ;)

Language attribute must die :D

On 11/7/12 10:24 PM, Walter Bright wrote:
> On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
>> I we were to allow for @foobar style UDA then "safe" would have to be
>> a reserved
>> keyword somehow. Otherwise I do not know what this would mean:
>>
>> struct safe { }
>> @safe void foobar() { }
>
> Yes, I agree this is a significant problem.
>

I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments.

Andrei

On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu wrote:
> I think it's solvable. The basic approach would be to plop types "safe", "nothrow" etc. in object.di and then let them just behave like all other arguments.

"nothrow" isn't actually an @attribute. So much for the value of consistency… :o)

David

On 11/8/12, David Nadlinger <see@klickverbot.at> wrote:
> On Thursday, 8 November 2012 at 00:03:34 UTC, Andrei Alexandrescu
> wrote:
> "nothrow" isn't actually an @attribute. So much for the value of
> consistency… :o)

Another classic inconsistency:
@disable and deprecated

Not only that but I keep writing the former as @disabled and get CT errors.

On 11/7/2012 4:03 PM, Andrei Alexandrescu wrote:
> On 11/7/12 10:24 PM, Walter Bright wrote:
>> On 11/7/2012 11:40 AM, Jonas Drewsen wrote:
>>> I we were to allow for @foobar style UDA then "safe" would have to be
>>> a reserved
>>> keyword somehow. Otherwise I do not know what this would mean:
>>>
>>> struct safe { }
>>> @safe void foobar() { }
>>
>> Yes, I agree this is a significant problem.
>>
>
> I think it's solvable. The basic approach would be to plop types "safe",
> "nothrow" etc. in object.di and then let them just behave like all other arguments.

Consider that if we do that, then someone will need to disambiguate with:

   @object.safe

which is ambiguous:

   @a.b .c x = 3;

or is it:

   @a .b.c x = 3;

?

Another problem is it pushes off recognition of @safe from the parser to the semantic analyzer. This has unknown forward reference complications.

Am Wed, 07 Nov 2012 16:19:56 +0100
schrieb Jacob Carlborg <doob@me.com>:

> On 2012-11-07 14:40, deadalnix wrote:
> 
> > I think D has already too many feature, and that many of them can be implemented as attribute + AST processing.
> >
> > D should work toward getting this AST stuff and stop adding new keywords all the time.
> 
> I completely agree.

Which features are that? It would likely require a major rewrite of many routines. Who would want to go through all that and the following wave of bugs - some of which may have already occurred in the past.

foreach and scope(...) lowerings are essentially AST operations. Are there other D features you would implement as AST processing, maybe a link to an earlier post ?

How close is Rust currently to offering flexible AST manipulation for lowerings/attributes/macros, does anyone know ?

-- 
Marco

On Wed, 07 Nov 2012 14:40:33 -0800
Walter Bright <newshound2@digitalmars.com> wrote:
> 
> Of course we all take it for granted that Basic sux and does everything wrong,

Which Basic? ;)   (<-- Just as one example)

On 11/7/2012 10:32 PM, Nick Sabalausky wrote:
> On Wed, 07 Nov 2012 14:40:33 -0800
> Walter Bright <newshound2@digitalmars.com> wrote:
>>
>> Of course we all take it for granted that Basic sux and does
>> everything wrong,
>
> Which Basic? ;)   (<-- Just as one example)
>

All of them!