digitalmars.D.bugs - [Issue 10193] New: Template args to UDA's
- d-bugmail puremagic.com (26/26) May 28 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10193
- d-bugmail puremagic.com (42/44) May 28 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10193
- d-bugmail puremagic.com (27/48) May 28 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10193
- d-bugmail puremagic.com (24/24) May 28 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10193
- d-bugmail puremagic.com (7/29) May 28 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10193
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
d-bugmail puremagic.com
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
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
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
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