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.
Comment #1 by iamthewilsonator — 2021-03-29T06:37:43Z
That second `void f()` should be called something different. Renaming it yields
onlineapp.d(20): Error: template `onlineapp.x` cannot deduce function from argument types `!()(S)`, candidates are:
onlineapp.d(11): `x(T)(T value)`
with `T = S`
must satisfy the following constraint:
` !is(T == struct)`
onlineapp.d(14): `x(T)(ref T value)
_even with_ -preview=rvaluerefparam
so it seems this issue should be closed and another one opened for the fact that this still doesn't compile?
Comment #2 by nick — 2022-12-27T11:44:28Z
> That second `void f()` should be called something different
Yes.
> so it seems this issue should be closed and another one opened for the fact that this still doesn't compile?
It can't compile because the first x overload doesn't take a struct, and the second one doesn't take an rvalue. So this issue is valid.
Comment #3 by robert.schadek — 2024-12-13T18:24:24Z