http://d.puremagic.com/issues/show_bug.cgi?id=10193

           Summary: Template args to UDA's
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: turkeyman@gmail.com


--- Comment #0 from Manu <turkeyman@gmail.com> 2013-05-28 06:45:05 PDT ---
So I've run into an expression I need 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.

This is blocking cross-platform support in std.simd.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10193


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


--- Comment #1 from Kenji Hara <k.hara.pg@gmail.com> 2013-05-28 08:48:27 PDT ---
(In reply to comment #0)
> Doesn't work:
>   @attribute("target", T) void func(string T)(...);

You can write it as follows.

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

void main()
{
    alias f1 = func!"a";
    alias f2 = func!"b";
    pragma(msg, __traits(getAttributes, f1));   // "a"
    pragma(msg, __traits(getAttributes, f2));   // "b"
    f1();
    f2();
}

----

It looks reasonable enhancement, but in general case it would introduce not trivial semantic issue.

Based on the current D language spec, prefix attribute is just rewritten to blocked attribute.

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

to:
@attribute("target", T) { void func(string T)() {} }

And block attribute can contain other declarations.

@attribute("target", T) {

    enum str = T.stringof;

    void func(string T)() {}
}

Well, if the enhancement is implemented, T would be deduced by the each call of template function foo. Then the enum value would become undeterministic.

I think it is not implementable.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10193


Manu <turkeyman@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


--- Comment #2 from Manu <turkeyman@gmail.com> 2013-05-28 16:56:57 PDT ---
(In reply to comment #1)
> Based on the current D language spec, prefix attribute is just rewritten to blocked attribute.
> 
> @attribute("target", T) void func(string T)() {}
> 
> to:
> @attribute("target", T) { void func(string T)() {} }
> 
> And block attribute can contain other declarations.
> 
> @attribute("target", T) {
> 
>     enum str = T.stringof;
> 
>     void func(string T)() {}
> }
> 
> Well, if the enhancement is implemented, T would be deduced by the each call of template function foo. Then the enum value would become undeterministic.
> 
> I think it is not implementable.

I see. Although I wonder if this is what users would expect. It seems more like an implementation detail.

I would assume a very distinct difference between:

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

The obvious outer scope being the difference.
In the first case, it is all (or appears to be) one declaration, and T should
be usable across the declaration.
In the second, there is clearly an outer scope, and no sane programmer would
expect that you should be able to access arguments to an inner declaration
within the outer scope.

So I guess the question becomes, does the lowering of attributes to a scoped
attribute actually make sense anymore with the possibility of UDA's?
It never mattered before since no hard attributes received arguments, but times
are different now...
The behaviour is no longer transparent, and kinda counter-intuitive.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10193


Diggory <diggsey@googlemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |diggsey@googlemail.com


--- Comment #3 from Diggory <diggsey@googlemail.com> 2013-05-28 20:49:48 PDT ---
It could be implemented by making the template rewrite rule happen before the attribute rewrite rule, so that this:

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

Goes to:

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

And then this:

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

Rather than the other way around like it does currently.

Block attributes would be unaffected as they are already expanded.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=10193



--- Comment #4 from Manu <turkeyman@gmail.com> 2013-05-28 22:10:42 PDT ---
(In reply to comment #3)
> It could be implemented by making the template rewrite rule happen before the attribute rewrite rule, so that this:
> 
> @attribute("target", T) void func(string T)(...);
> 
> Goes to:
> 
> template func(string T) {
>     @attribute("target", T) void func(...);
> }
> 
> And then this:
> 
> template func(string T) {
>     @attribute("target", T) {
>         void func(...);
>     }
> }
> 
> Rather than the other way around like it does currently.
> 
> Block attributes would be unaffected as they are already expanded.

I like the way this man thinks! :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------