www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10193] New: Template args to UDA's

reply d-bugmail puremagic.com writes:
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



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: -------
May 28 2013
next sibling parent d-bugmail puremagic.com writes:
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




 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: -------
May 28 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10193


Manu <turkeyman gmail.com> changed:

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




 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: -------
May 28 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10193


Diggory <diggsey googlemail.com> changed:

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



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: -------
May 28 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=10193





 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: -------
May 28 2013