Template type deduction and specialization

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/21/15 2:35 AM, Daniel Kozák via Digitalmars-d-learn wrote:
>
> On Wed, 20 May 2015 17:23:05 -0700
> Ali Çehreli via Digitalmars-d-learn <digitalmars-d-learn at puremagic.com>
> wrote:
>
>> On 05/20/2015 04:10 PM, Mike Parker wrote:
>>> On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák wrote:
>>>> DOC say  `may not have` not `must not have` ;-)
>>>>
>>>
>>> OK, if that's the intent, it needs to be reworded. As it stands, it
>>> looks more like it's saying specialization is not permissible,
>>> rather than what "might" be possible.
>>
>> That's the only meaning that I get: The doc means "must not". Yet, as
>> you've shown, the behavior does not match the doc.
>>
>> Ali
>>
> 1.) we could fix just doc - easiest, but inconsistent

Before doing this, we have to understand what works and what doesn't. 
It's not clear to me.

> 2.) remove implicit deduction even for fun(T:char)(T c) and all other
> specialization - code breakage so imho not good

I don't think this is possible, this would break lots of existing code.

> 3.) fix doc and allow even fun(T:T*)(T* p) - same as 2

I agree with this fix. I don't understand why specialization should 
disqualify IFTI. Can someone explain this rationale besides "because the 
docs say so"?

A possible explanation is that the specialization doesn't resolve to a 
*specific type* but instead resolves to a *flavor of type*.

For example, does this work?

foo(T : int*)(T t)

That would make some sense at least, but I don't understand why this 
rule is in place.

-Steve