[Issue 14675] New: template specialization for T: T* and T: T[] has issues with IFTI

[via Digitalmars-d-bugs]

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 at puremagic.com
          Reporter: schveiguy at 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.

--