• via Digitalmars-d-bugs (64/65) Aug 20 2014 https://issues.dlang.org/show_bug.cgi?id=13340

via Digitalmars-d-bugs <digitalmars-d-bugs puremagic.com> writes:

https://issues.dlang.org/show_bug.cgi?id=13340

          Issue ID: 13340
           Summary: Improve error message for overload resolution error
           Product: D
           Version: D2
          Hardware: x86_64
                OS: Windows
            Status: NEW
          Severity: enhancement
          Priority: P1
         Component: DMD
          Assignee: nobody puremagic.com
          Reporter: turkeyman gmail.com

This (in a more complicated context) had me scratching my head for over an
hour. A better error message REALLY would have helped.

This code:

struct S
{
  int x;
}

S f()
{
  return S();
}

void x(T)(T value) if(!is(T == struct))
{
}
void x(T)(ref T value) if(is(T == struct))
{
}

void f()
{
  x(f());
}


Error: template x cannot deduce function from argument types !()(S), candidates
are:
x(T)(T value) if (!is(T == struct))
x(T)(ref T value) if (is(T == struct))


The thing is, the error message is telling me it can't decide which function to
choose. It should be certain which function to choose, f() returns a struct,
and only one of them can accept a struct. There should be no ambiguity which
one it chooses.

Once it's eliminated candidates by their constraints though, then there is a
legitimate error, but the compiler wouldn't tell me the actual error (can't
pass rvalue -> ref (...I thought we agreed on a fix for this years ago!!!
_<)).

Hidden deep inside generic code, it was very hard to understand.

I guess the compiler realised that none of the overloads could be called with
the given args, and then complained about overload selection and just presented
all overloads.


I suggest:

Eliminate candidates that failed the constraint checks; I think it's reasonable
for users to assume the constraints are firm commitments. They are not subject
to implicit conversions and such like function args.

Now the only overloads left are the ones the user needs to consider relating to
their selection problem. This will offer better visibility of the conflict in
question.

If there is only one left, then provide the error message relating to calling
that function with the given args, as if there were no overloads. In this case,
I would have received the error "can't pass rvalue to ref", which is what I
really wanted to know.


I've run into this problem and lost a significant amount of time on numerous
occasions now, but this one was deep in the thicket. I think this suggested
behaviour would help users isolate their problem much faster.

--