On Sunday, 6 January 2013 at 14:58:07 UTC, Andrei Alexandrescu wrote:
> On 1/6/13 9:25 AM, Philippe Sigaud wrote:
>> That's too bad, because declaring UDA is simple, and receiving them with
>> arguments is easy also. There is a fundamental imbalance in having
>> having propagating attributes through functions so difficult.
>
> <brokenrecord>For designing attributes that navigate with types templates would be the solution of choice.</brokenrecord>
>
> Andrei

Isn't it better to achieve this with a template ?

On Fri, Jan 4, 2013 at 9:58 PM, Walter Bright

> <newshound2@digitalmars.com <mailto:newshound2@**digitalmars.com<newshound2@digitalmars.com>>>
>> wrote:
>>
>>
>>     Module declarations aren't declarations.
>>
>>
>> Great quote :)
>>
>>
>>
> Walter often argues in terms of DMD implementation details.
>
> ...
> struct ModuleDeclaration
> {
>     Identifier *id;
> ...
>
> Too low-level, I suppose ;) What he said is also true from the grammar
PoV. It's just funny expressed that way.
I keep forgetting modules are not first-class in D (it's not a criticism, I
don't what I'd do with first-class modules)

On Sun, Jan 6, 2013 at 11:24 PM, deadalnix <deadalnix@gmail.com> wrote:

> On Saturday, 5 January 2013 at 22:14:47 UTC, Walter Bright wrote:
>
>> On 1/5/2013 2:06 PM, Philippe Sigaud wrote:
>>
>>> But why is @(MyType) accepted, whereas @(int) is not?
>>>
>>
>> Because it's looking for an expression inside the parents, and int is not an expression.
>>
>
> And mytype is an expression ?????
>

Same thought here.

On 01/06/2013 07:24 PM, Philippe Sigaud wrote:
>
> Can attributes be defined by templates arguments?
>
>
> @(T) class C(T) : T { }
>
> Answer: no. OK.

This works:

template C(T){ @T class C : T { } }

The above appears to annotate the template itself, which is inconsistent. You should probably file a bug report.

On 01/06/2013 11:27 PM, deadalnix wrote:
> On Sunday, 6 January 2013 at 14:58:07 UTC, Andrei Alexandrescu wrote:
>> On 1/6/13 9:25 AM, Philippe Sigaud wrote:
>>> That's too bad, because declaring UDA is simple, and receiving them with
>>> arguments is easy also. There is a fundamental imbalance in having
>>> having propagating attributes through functions so difficult.
>>
>> <brokenrecord>For designing attributes that navigate with types
>> templates would be the solution of choice.</brokenrecord>
>>
>> Andrei
>
> Isn't it better to achieve this with a template ?

No, it is equivalent.

On 01/06/2013 11:24 PM, deadalnix wrote:
> On Saturday, 5 January 2013 at 22:14:47 UTC, Walter Bright wrote:
>> On 1/5/2013 2:06 PM, Philippe Sigaud wrote:
>>> But why is @(MyType) accepted, whereas @(int) is not?
>>
>> Because it's looking for an expression inside the parents, and int is
>> not an expression.
>
> And mytype is an expression ?????

Sure!

...
struct IdentifierExp : Expression
{
    Identifier *ident;
    Declaration *var;
...

On 1/6/2013 2:24 PM, deadalnix wrote:
> On Saturday, 5 January 2013 at 22:14:47 UTC, Walter Bright wrote:
>> On 1/5/2013 2:06 PM, Philippe Sigaud wrote:
>>> But why is @(MyType) accepted, whereas @(int) is not?
>>
>> Because it's looking for an expression inside the parents, and int is not an
>> expression.
>
> And mytype is an expression ?????

Parsing happens before semantic analysis. Hence, MyType looks like an expression.

On Monday, 7 January 2013 at 00:38:35 UTC, Walter Bright wrote:
> On 1/6/2013 2:24 PM, deadalnix wrote:
>> On Saturday, 5 January 2013 at 22:14:47 UTC, Walter Bright wrote:
>>> On 1/5/2013 2:06 PM, Philippe Sigaud wrote:
>>>> But why is @(MyType) accepted, whereas @(int) is not?
>>>
>>> Because it's looking for an expression inside the parents, and int is not an
>>> expression.
>>
>> And mytype is an expression ?????
>
> Parsing happens before semantic analysis. Hence, MyType looks like an expression.

OK, but if int is invalid, should semantic analysis reject MyType as well ?

On 1/6/2013 5:06 PM, deadalnix wrote:
> On Monday, 7 January 2013 at 00:38:35 UTC, Walter Bright wrote:
>> On 1/6/2013 2:24 PM, deadalnix wrote:
>>> On Saturday, 5 January 2013 at 22:14:47 UTC, Walter Bright wrote:
>>>> On 1/5/2013 2:06 PM, Philippe Sigaud wrote:
>>>>> But why is @(MyType) accepted, whereas @(int) is not?
>>>>
>>>> Because it's looking for an expression inside the parents, and int is not an
>>>> expression.
>>>
>>> And mytype is an expression ?????
>>
>> Parsing happens before semantic analysis. Hence, MyType looks like an expression.
>
> OK, but if int is invalid, should semantic analysis reject MyType as well ?

Tuples accept both types and expressions, and the semantic analyzer loads it into the tuple.

On 01/07/2013 01:38 AM, Walter Bright wrote:
> On 1/6/2013 2:24 PM, deadalnix wrote:
>> On Saturday, 5 January 2013 at 22:14:47 UTC, Walter Bright wrote:
>>> On 1/5/2013 2:06 PM, Philippe Sigaud wrote:
>>>> But why is @(MyType) accepted, whereas @(int) is not?
>>>
>>> Because it's looking for an expression inside the parents, and int is
>>> not an
>>> expression.
>>
>> And mytype is an expression ?????
>
> Parsing happens before semantic analysis. Hence, MyType looks like an
> expression.

Sure, that is how the compiler currently works. The compiler is an inadequate reference at this point. (Eg. I am still reducing the massive breakage introduced by 2.061 regressions. Mostly 'forward reference' errors -- mentioned nowhere in the spec, and seemingly introduced in order to 'fix' ICEs.)

Why does it make sense from the standpoint of language design?

The compiler should obviously use the part of the parser that parses template arguments to parse UDA's. I am surprised this is not what is done.

Also, this particular problem would not exist in the first place if basic types just were treated like expressions in the parser. I am not familiar with DMD, but I bet the special casing of built-ins leaves an ugly trail in the code base.