digitalmars.D.bugs - [Issue 14675] New: template specialization for T: T* and T: T[] has
- via Digitalmars-d-bugs (52/52) Jun 10 2015 https://issues.dlang.org/show_bug.cgi?id=14675
https://issues.dlang.org/show_bug.cgi?id=14675 Issue ID: 14675 Summary: template specialization for T: T* and T: T[] has issues with IFTI Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: spec Severity: normal Priority: P1 Component: dmd Assignee: nobody puremagic.com Reporter: schveiguy yahoo.com Some background: http://forum.dlang.org/post/rvflnpxwzetpcphwxrgx forum.dlang.org When a specialization of the form: void foo(T : T*)(T* t) void foo(T : T[])(T[] t) exists in a function template, it cannot be matched for IFTI, only explicit instantiation: int i; foo(&i); // error foo!(int *)(&i); // ok However, this will match both calls: void foo(T : U*, U)(T t) void foo(T : U[], U)(T t) The docs say that parameters involved with specialization cannot be used for IFTI, but that simply isn't the case for almost all specializations (2 examples are the secondary forms above). Just these 2 as far as I can tell don't work. First, their existence is redundant. The secondary forms are superior in almost every way. Second, they are confusing. A T is specialized as a T*? But then it's not? Third, if they must exist, I think they should be usable with IFTI. There doesn't seem to be any reasonable explanation as to why these particular templates cannot be used for IFTI. As an example of why this is important, consider the following: void foo(T)(T t) { /* impl 1 */} void foo(T:T*)(T* t) { /* impl 2 */} int i; foo(&i); // calls impl 1 foo!(typeof(&i))(i) // calls impl 2 This makes absolutely no sense, and seems extremely error prone. Valid resolutions here: 1. Deprecate. This would break some code, but the ability to use the second form at least gives a path forward. 2. Allow IFTI. At least this would not break code (at least not *reasonable* code), but could potentially change code paths. It's possible someone has exploited this confusing behavior to have two code paths for calling a function with the same parameters. I don't think we should support this though. --
Jun 10 2015