Bug 1672 – Literals should match template alias arguments
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
x86
OS
Linux
Creation time
2007-11-15T12:35:00Z
Last change time
2015-06-09T01:14:21Z
Keywords
spec
Assigned to
bugzilla
Creator
andrei
Comments
Comment #0 by andrei — 2007-11-15T12:35:45Z
Consider an implementation of a sort function with configurable comparison:
template sort(alias comparison)
{
... define a sort function ...
}
A candidate for "comparison" is a function, e.g.:
bool less(int a, int b) { return a < b; }
sort!(less)(array);
Let's say we want to make sort take a compile-time string that contains the body of the comparison, such that:
sort!("a < b")(array);
has the same effect as the more verbose version above. (By convention, the string names the compared objects "a" and "b".) The compiler does not accept the string literal; it won't match a literal. What it does accept is:
static const string less = "a < b";
sort!(less)(array);
The problem is that we got back to the same verbosity as before. Since this is likely to become a very useful idiom, the compiler should automatically transform a compile-time value passed as an alias into an anonymous alias.
Comment #1 by shro8822 — 2007-11-15T13:30:32Z
What does this have over:
template sort(char[] comp)
are you hoping to be able to pass either a string or a function?
Comment #2 by andrei — 2007-11-15T13:33:25Z
(In reply to comment #1)
> What does this have over:
>
> template sort(char[] comp)
>
> are you hoping to be able to pass either a string or a function?
Yes, the point is to pass either a string, a function, a delegate, or a struct/class, and have the sort template discern how to proceed with static if's.
Comment #3 by shro8822 — 2007-11-15T13:37:14Z
How do you plan to pass delegates? I have wanted to pass local values to a template but couldn't find a way to do it.
Comment #4 by samukha — 2008-11-13T01:56:24Z
Can we set this one to fixed?
Comment #5 by andrei — 2008-11-13T08:04:51Z
(In reply to comment #4)
> Can we set this one to fixed?
>
Yah, I think so.