[Issue 14675] 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

--- Comment #2 from Steven Schveighoffer <schveiguy at yahoo.com> ---
Well, if T: T* isn't going to be removed, and we cannot use IFTI with it, we
should at least update the documentation. The documentation doesn't seem
accurate, since specializations do not disqualify IFTI obviously.

There is definitely room to add docs to template specialization. I'll see if I
can update the docs to guide people away from making these mistakes.

(In reply to Kenji Hara from comment #1)
> It takes one place in template parameter list. When a template argument is
> _explicitly given_ on the position, it will deduce the parameter T, by
> matching the argument to the form `T*`.
> That's the point. Even if you explicitly give template argument, T is always
> deduced.

This doesn't make a whole lot of sense, because in most cases, when you
EXPLICITLY specify a template parameter, you are specifying the parameter on
the left of the colon, and it only matches the specialization if it matches the
pattern on the right:

foo(T : ulong)(T t)
foo(T : U*, U)(T t)

foo!int(1)); // T == int
foo!(int *)(null); // T == int *

But in this case, the instantiation doesn't specify T, it specifies, well, I
don't know *what* it specifies!

foo(T : T*)(T *)

foo!(int *)(null); // T == int

So you CAN'T specify T directly, and you can't access the parameter you DID
specify directly.

I feel like it's shorthand for this:

foo(U : T*, T)(U *t)

But U isn't actually listed or accessible. BTW, the above has the same issue
with IFTI.

I think this is an anti-pattern that should always be avoided. And I think that
the T* and T[] forms are the only specializations that fall under this pattern.
Is there any other time you can explicitly instantiate a template, but the
parameter you explicitly pass is not used for the actual parameter?

--