Bug 1597 – It is not possible to specialize template on associative array.

Status
RESOLVED
Resolution
WONTFIX
Severity
enhancement
Priority
P2
Component
dmd
Product
D
Version
D1 (retired)
Platform
All
OS
All
Creation time
2007-10-19T17:24:42Z
Last change time
2019-08-26T13:31:17Z
Assigned to
No Owner
Creator
Marcin Kuszczak

Comments

Comment #0 by aarti — 2007-10-19T17:24:42Z
void parse(T)() { } //What to write here??? void parse(T : ?????)() { } void main() {      parse!(int[char[]])(); }
Comment #1 by aarti — 2007-10-19T17:32:23Z
Also syntax of matching for normal arrays is cryptic. It would be better to have following syntax for matching arrays: void parse(T : E[])() {} which is much more clear (match types which are collections of elements of type E). Similarly some cleanups could be done in is() expression for types. proposed syntax for associative arrays: void parse(T : V[K])() {} Related proposal from Bill Baxter: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D.learn&article_id=9858
Comment #2 by andrei — 2007-10-19T17:35:45Z
While acknowledging this as a bug in the language, below is a fix for the time being: import std.stdio; void parse(T, U = void, V = void)() { writeln("Wuddever"); } void parse(T : U[V], U, V)() { writeln("Hash"); } void main() { parse!(int[char[]])(); parse!(int[])(); parse!(int)(); } The second suggestion: void parse(T : E[])() {} won't work because it's unclear whether E is a newly-introduced symbol ("must be inferred") or a previously-defined symbol ("must be E that I defined in this module").
Comment #3 by wbaxter — 2007-10-19T17:52:19Z
(In reply to comment #2) > won't work because it's unclear whether E is a newly-introduced symbol ("must > be inferred") or a previously-defined symbol ("must be E that I defined in this > module"). What's wrong with the C++ way of specifying specializations? Just void parse(T[])() {}
Comment #4 by andrei — 2007-10-19T18:04:28Z
(In reply to comment #3) > (In reply to comment #2) > > won't work because it's unclear whether E is a newly-introduced symbol ("must > > be inferred") or a previously-defined symbol ("must be E that I defined in this > > module"). > > What's wrong with the C++ way of specifying specializations? > Just > void parse(T[])() {} > It has the same problem. Consider: // wanna specialize on hashes, and also pattern match T and U! Cool! void parse(T[U])() {} Now if the same module adds or imports a type called U, a bad time is being had.
Comment #5 by aarti — 2007-10-19T18:19:50Z
(In reply to comment #2) But in other hand probably you will admit that current solution: void parse(T : T[]) is even worse? Inside function you get something completely different than you put when instantiating template. Inside function T means element of array, while it is instantiated as T[]. So maybe: void parse(T : auto E[]) {} and void parse(T : auto V[K]) {} to say that these symbols are inferred?
Comment #6 by andrei — 2007-10-19T18:35:43Z
(In reply to comment #5) > (In reply to comment #2) > But in other hand probably you will admit that current solution: > void parse(T : T[]) > > is even worse? > > Inside function you get something completely different than you put when > instantiating template. Inside function T means element of array, while it > is instantiated as T[]. That's very ugly but Walter cannot be convinced to give it up. > So maybe: > void parse(T : auto E[]) {} and > void parse(T : auto V[K]) {} > to say that these symbols are inferred? This idea has been iterated a number of times. In the end, there was admission that the current syntax of appending the symbols to the list is as good as any other.
Comment #7 by razvan.nitu1305 — 2019-08-26T13:31:17Z
Per Andrei's response this is a WONTFIX issue. Marking as such.