http://d.puremagic.com/issues/show_bug.cgi?id=1650

           Summary: Incorrect overload selected with IFTI
           Product: D
           Version: 1.023
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: sean@f4.ca


Given the following code:

    void proc(T)( T val )
    {
        printf( "proc:T\n" );
    }

    void proc(T,U=void)( T[] val )
    {
        printf( "proc:T[]\n" );
    }

    void main()
    {
        proc( 0 );
        proc( "abc".dup );
    }

I would expect to see:

    proc:T
    proc:T[]

Because proc:T[] is more specialized and thus should be preferred for the second call.  Instead, it prints:

    proc:T
    proc:T

Interestingly, moving the dummy parameter to the first function:

    void proc(T,U=void)( T val )
    {
        printf( "proc:T\n" );
    }

    void proc(T)( T[] val )
    {
        printf( "proc:T[]\n" );
    }

    void main()
    {
        proc( 0 );
        proc( "abc".dup );
    }

Results in the expected behavior:

    proc:T
    proc:T[]

I can only assume this means that the dummy parameters required to support overloading are considered for determining how specialized a particular function is, even though they are not used in the function parameter list.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1650


smjg@iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com
           Keywords|                            |spec




------- Comment #1 from smjg@iname.com  2007-11-10 16:13 -------
I'm not sure what's meant to happen here.  Both templates match the argument type, but it could be the template parameters, not the function parameters, that somehow determine which template is the more specific match.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1650





------- Comment #2 from sean@f4.ca  2007-11-11 10:15 -------
The second overload is a more exact match for array parameters.  My original bug report shows what the expected behavior is here.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1650





------- Comment #3 from smjg@iname.com  2007-11-11 10:38 -------
(In reply to comment #2)
> The second overload is a more exact match for array parameters.

There's no such thing as a "more exact match" - either a match is exact or it isn't.  In this case, both are exact matches.

> My original bug report shows what the expected behavior is here.

Remarks like that are no use without an indication of how you have come to that conclusion.  What statement(s) in the spec are you going by, exactly?


-- 

d-bugmail@puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=1650
>
> ------- Comment #3 from smjg@iname.com  2007-11-11 10:38 -------
> (In reply to comment #2)
>> The second overload is a more exact match for array parameters. 
> 
> There's no such thing as a "more exact match" - either a match is exact or it
> isn't.  In this case, both are exact matches.

Sorry.  I meant "more specialized match."  This is how C++ behaves, and I expected D to behave the same way.

>> My original bug report shows what the expected behavior is here.
> 
> Remarks like that are no use without an indication of how you have come to that
> conclusion.  What statement(s) in the spec are you going by, exactly?

None.  By Walter's statement to me in the newsgroup a year or so ago that D templates would behave this way.


Sean

http://d.puremagic.com/issues/show_bug.cgi?id=1650





------- Comment #5 from sean@f4.ca  2008-01-15 17:06 -------
I don't know why the previous reply is said to have come from Sean Chittenden, but no mater.  If it helps, I verified that this was a bug before submitting this ticket because the book covers this topic and I wanted to be sure the discussion was correct.  I'm adding this comment to clarify the situation because the book is now available and a question or two has come up about the related (currently broken) example.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1650





------- Comment #6 from bugzilla@digitalmars.com  2008-06-13 04:03 -------
The "most specialized" template selection algorithm works with the template
parameters, not the function parameters.
Currently, the only way to make this example work is:

void proc(T, U=void)( T val )
{
    printf( "proc:T\n" );
}

void proc(T:U[], U)( T val )
{
    printf( "proc:T[]\n" );
}

void main()
{
    proc( 0 );
    proc( "abc".dup );
}

because (U[],U) is a match for (T,U), but (T,U) is not a match for (U[],U).


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1650





------- Comment #7 from sean@invisibleduck.org  2008-06-14 12:45 -------
So are you saying that the wrong function is selected because D doesn't have ADL?  And can you explain why the first template is more specialized than the other?  Is it simply because it has fewer template parameters?


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1650





------- Comment #8 from bugzilla@digitalmars.com  2008-06-15 00:55 -------
> So are you saying that the wrong function is selected because D doesn't have
ADL?

No, this has nothing whatsoever to do with ADL. Template functions are overloaded based on the template parameters, not the function parameters.

>And can you explain why the first template is more specialized than the
other?

Specialization heirarchy is determined the same way as in C++. Template A is
"at least as specialized" as template B if the template parameters of A can be
used to call B. In the examples, (T) can call (T,U=void), so it is at least as
specialized. But (T,void) cannot call (T), so it is equally or less
specialized. Therefore (T) is more specialized.

(I know this is a bit of a bear to slog through.)


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=1650





------- Comment #9 from sean@invisibleduck.org  2008-06-15 11:12 -------
Okay, I understand the logic, though I'm not sure I understand the reasoning behind it.  I would expect the more correct set of function parameters to be chosen among the set of instantiable function templates rather than the reverse.

So it appears this all came up because we currently need to add dummy template parameters to disambiguate between overloads--adding the dummy parameter effectively changes the overload decisions for the set of matching functions. You've changed the equation a bit by making one template a specialization of the other, so the dummy parameter U could be dropped altogether.  Given that dummy parameters seem to alter the overloading behavior of a set of functions, I'm hesitant to endorse it as a viable option for overloading template functions.  Perhaps this proposed solution should be reconsidered?


--