So I've run into an expression I need to be able to implement std.simd properly for GDC/LDC.

Doesn't work:
  @attribute("target", T) void func(string T)(...);

In this case, currently, the UDA can't receive the template arg that was given to the function.

I require that attributes on templates be able to make use of the template args, since the template arg given may affect the attribute in some circumstances.

On Tuesday, 28 May 2013 at 13:41:42 UTC, Manu wrote:
> So I've run into an expression I need to be able to implement std.simd
> properly for GDC/LDC.
>
> Doesn't work:
>   @attribute("target", T) void func(string T)(...);
>
> In this case, currently, the UDA can't receive the template arg that was
> given to the function.
>
> I require that attributes on templates be able to make use of the template
> args, since the template arg given may affect the attribute in some
> circumstances.

Can you not move the template outside the attribute like this?:

template func(string T) {
    @attribute("target", T) void func(...);
}

On 29 May 2013 10:46, Diggory <diggsey@googlemail.com> wrote:

> On Tuesday, 28 May 2013 at 13:41:42 UTC, Manu wrote:
>
>> So I've run into an expression I need to be able to implement std.simd properly for GDC/LDC.
>>
>> Doesn't work:
>>   @attribute("target", T) void func(string T)(...);
>>
>> In this case, currently, the UDA can't receive the template arg that was given to the function.
>>
>> I require that attributes on templates be able to make use of the template args, since the template arg given may affect the attribute in some circumstances.
>>
>
> Can you not move the template outside the attribute like this?:
>
> template func(string T) {
>     @attribute("target", T) void func(...);
> }
>

Yes, that's Kenji's initial suggestion, which I can use for now, but it
feels like a workaround.
It feels pretty lame to have to wrap select functions in an arbitrary outer
scope, and it also has some subtle implications; how does
auto-complete/intellisense see it? As a template, or as whatever it
resolves to?
The latter would imply some pretty powerful semantic analysis, and if
there's static logic inside the template? The IDE basically won't work
properly for any of these functions.

Either way, the attribute certainly looks like it's part of the declaration, I think any reasoning programmer would assume that it is. It's only a DMD implementation detail that says otherwise, and it's not particularly intuitive to a programmer.

2013/5/29 Manu <turkeyman@gmail.com>

> Either way, the attribute certainly looks like it's part of the declaration, I think any reasoning programmer would assume that it is. It's only a DMD implementation detail that says otherwise, and it's not particularly intuitive to a programmer.
>

It's not a dmd implementation detail. It is part of current D language design. dmd works as well. No bug there, so this is definitely an enhancement.

But I can agree that is a little not good from human sense. I know a related issue.

struct S {
    immutable int foo() {}    // immutable is prefix attribute (==storage
class)
}

In above, `immutable` would be applied to the declaration `foo`, not its return type `int`.

But, changing semantics would break much existing code. Your enhancement belongs same area. We need to get agreement of D programmers first.

Kenji Hara

On 29 May 2013 11:18, Kenji Hara <k.hara.pg@gmail.com> wrote:

> 2013/5/29 Manu <turkeyman@gmail.com>
>
>> Either way, the attribute certainly looks like it's part of the declaration, I think any reasoning programmer would assume that it is. It's only a DMD implementation detail that says otherwise, and it's not particularly intuitive to a programmer.
>>
>
> It's not a dmd implementation detail. It is part of current D language design. dmd works as well. No bug there, so this is definitely an enhancement.
>
> But I can agree that is a little not good from human sense. I know a related issue.
>
> struct S {
>     immutable int foo() {}    // immutable is prefix attribute (==storage
> class)
> }
>
> In above, `immutable` would be applied to the declaration `foo`, not its return type `int`.
>
> But, changing semantics would break much existing code. Your enhancement belongs same area. We need to get agreement of D programmers first.
>

Yeah, that's a good point, I've never liked that ambiguity.
I always write: immutable(int) foo() {}
Otherwise I never really know what to expect.

> Yes, that's Kenji's initial suggestion, which I can use for

Ah, didn't see it because the forum keeps breaking threads up into little pieces...

On Tue, 28 May 2013 21:08:42 -0400, Manu <turkeyman@gmail.com> wrote:

> On 29 May 2013 10:46, Diggory <diggsey@googlemail.com> wrote:
>
>> Can you not move the template outside the attribute like this?:
>>
>> template func(string T) {
>>     @attribute("target", T) void func(...);
>> }
>>
>
> Yes, that's Kenji's initial suggestion, which I can use for now, but it
> feels like a workaround.
> It feels pretty lame to have to wrap select functions in an arbitrary outer
> scope, and it also has some subtle implications; how does
> auto-complete/intellisense see it? As a template, or as whatever it
> resolves to?

It's not a workaround, nor arbitrary.

In fact:

func(string T)(...)

is EXACTLY equivalent to:

template func(string T)
{
   func(...)
}

The compiler implicitly converts the former to the latter.

In fact, the formal name of func!"foo"() is func!"foo".func() in both cases.

> The latter would imply some pretty powerful semantic analysis, and if
> there's static logic inside the template? The IDE basically won't work
> properly for any of these functions.

Any conditional compilation breaks IFTI.  This is required, since the "magic" of IFTI means it must partially instantiate the template to see whether the function parameters match.  It could very easily get stuck in the weeds through some arbitrary conditional compilation.

> Either way, the attribute certainly looks like it's part of the
> declaration, I think any reasoning programmer would assume that it is. It's
> only a DMD implementation detail that says otherwise, and it's not
> particularly intuitive to a programmer.

On this, I agree.  But it is important to remember that a function template is first a template and then a function.  When you apply attributes to it, you are applying it to the outer-most piece -- the template.  And IATI (implicit attribute template instantiation) isn't available yet :)

I think it's awesome that IFTI handles this messy detail, and it would be nice if uda's were part of that messy detail.

-Steve

On Wednesday, May 29, 2013 11:28:06 Manu wrote:
> On 29 May 2013 11:18, Kenji Hara <k.hara.pg@gmail.com> wrote:
> > But I can agree that is a little not good from human sense. I know a related issue.
> > 
> > struct S {
> > 
> > immutable int foo() {} // immutable is prefix attribute (==storage
> > 
> > class)
> > }
> > 
> > In above, `immutable` would be applied to the declaration `foo`, not its return type `int`.
> > 
> > But, changing semantics would break much existing code. Your enhancement belongs same area. We need to get agreement of D programmers first.
> 
> Yeah, that's a good point, I've never liked that ambiguity.
> I always write: immutable(int) foo() {}
> Otherwise I never really know what to expect.

Well, it's not actually ambiguous at all. It's just undesirable. If the const, immutable, or inout uses parens around the return type, then it's the return type which is const, immutable, or inout. In all other cases, it's the function (and thus the this pointer). So, it's completely clear if you know the rules, but the rules suck. Unfortunately, if function attributes which could affect the return type could only go on the right (as is the case with C++), then those function attributes would be inconsistent with the others, and Walter doesn't like that. Enforcing that all function attributes always go on the right would fix that, but I expect that that's too different from C++, Java, etc. for that to have ever been acceptable, and at this point, it would break too much code for Walter to agree to change it.

- Jonathan M Davis