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@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@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

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@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@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

On Thu, 21 May 2015 09:58:16 -0400
Steven Schveighoffer via Digitalmars-d-learn
<digitalmars-d-learn@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@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@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

On 5/21/15 10:15 AM, Daniel Kozák via Digitalmars-d-learn wrote:

> 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
>

Ugh, that was not what my reading of the docs seemed to suggest:

"Function template type parameters that are to be implicitly deduced may not have specializations"

I misread that to mean *templates* that have specializations cannot be used for IFTI. Now I see that the rule is talking not about templates but *template type parameters*.

But the more I look at this, the more I think this is a bad code smell. I can't see any logical reason to do something different with an implicit deduction vs. an explicit call. Especially in the face of other code that Can anyone come up a valid use case for this? Even one that is a hack?

I'll note that if you replace the specialization with:

f(T : int *)(T t)

it calls the specialized version twice. Clearly, the rule is not properly described or not properly implemented.

I would like to hear from Walter on this, what are the thoughts behind this rule?

-Steve