https://issues.dlang.org/show_bug.cgi?id=14675
--- Comment #2 from Steven Schveighoffer <schvei...@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? --