Template type deduction and specialization

[Steven Schveighoffer via Digitalmars-d-learn]

On 5/21/15 9:14 AM, Daniel Kozak wrote:
> On Thursday, 21 May 2015 at 13:12:36 UTC, Daniel Kozák wrote:
>>
>> On Thu, 21 May 2015 08:54:54 -0400
>> Steven Schveighoffer via Digitalmars-d-learn
>> <digitalmars-d-learn at puremagic.com> wrote:
>>
>>> 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"?
>>>
>>
>> But this will break more code than 2. So it is impossible to fix it.
>
> Not more, but it will be worst, because it could change behaviour of
> program without error message

How so? My understanding is that it's illegal to call a function with 
specializations when IFTI is involved. This means code that currently 
doesn't compile, will compile. But what working code base has 
non-compiling code? I guess some __traits(compiles) calls would change, 
but I don't see the harm in this? You can call the function with an 
explicit instantiation, calling it with an implicit one isn't going to 
change the semantic meaning of the call.

In other words, code that does this:

foo(x);

that doesn't compile, will start to compile as if you did:

foo!(typeof(x))(x).

How does this break code?

And how does it break more code than 2?

-Steve