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.