Template type deduction and specialization

[Daniel Kozak via Digitalmars-d-learn]

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