Template type deduction and specialization

[Daniel Kozák via Digitalmars-d-learn]

On Thu, 21 May 2015 09:58:16 -0400
Steven Schveighoffer via Digitalmars-d-learn
<digitalmars-d-learn at puremagic.com> wrote:

> 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

import std.stdio;

void f(T:T*)(T* t)
{
    writeln("before change this is not called");
}

void f(T)(T t)
{
    writeln("before change this is called");
}


void main() {
    int val;
    f(&val);
    f!(int*)(&val);
}

now it prints:
before change this is called
before change this is not called

but if we make change as you suggest this will be print:

before change this is not called
before change this is not called