www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Looks like wrong error message

reply welkam <wwwelkam gmail.com> writes:
Error says that it cant deduce function from argument types but 
in reality it fails to meet function template constraints. In 
this case !is(CommonType!(staticMap!(ElementType, 
staticMap!(Unqual, Ranges))) == void)

In human terms it means that arguments are not the same type. Is 
this require bug report or it works as expected?

Code:
void main() {
     import std.range : chain;
     string s = "string";
     auto arrayOfStrings = ["string"];
     arrayOfStrings.chain(s);
}

error:
Main.d(9): Error: template std.range.chain cannot deduce function 
from argument types !()(string[], string), candidates are:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(894):  
       std.range.chain(Ranges...)(Ranges rs) if (Ranges.length > 0 
&& allSatisfy!(isInputRange, staticMap!(Unqual, Ranges)) && 
!is(CommonType!(staticMap!(ElementType, staticMap!(Unqual, 
Ranges))) == void))
Jan 28
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, January 28, 2018 20:02:48 welkam via Digitalmars-d-learn wrote:
 Error says that it cant deduce function from argument types but
 in reality it fails to meet function template constraints. In
 this case !is(CommonType!(staticMap!(ElementType,
 staticMap!(Unqual, Ranges))) == void)

 In human terms it means that arguments are not the same type. Is
 this require bug report or it works as expected?

 Code:
 void main() {
      import std.range : chain;
      string s = "string";
      auto arrayOfStrings = ["string"];
      arrayOfStrings.chain(s);
 }

 error:
 Main.d(9): Error: template std.range.chain cannot deduce function
 from argument types !()(string[], string), candidates are:
 C:\D\dmd2\windows\bin\..\..\src\phobos\std\range\package.d(894):
        std.range.chain(Ranges...)(Ranges rs) if (Ranges.length > 0
 && allSatisfy!(isInputRange, staticMap!(Unqual, Ranges)) &&
 !is(CommonType!(staticMap!(ElementType, staticMap!(Unqual,
 Ranges))) == void))
There is nothing incorrect about the error message. The compiler looked at all of the functions in the overload set, and it found none that matched. The reason that it found none that matched was because it couldn't find any function template where those arguments passed the template constraint, and it tells you so. So, there is no bug here in the sense that the compiler is telling you the wrong thing. You can certainly open a bug report arguing that the error messages isn't human-friendly enough and suggest alternatives, and something along those lines may be implemented, but the message isn't actually wrong. So, feel free to open a bug report. However, you're not going to get an error message that says anything like "the arguments aren't the same type." The compiler doesn't understand what the template constraint means in "human terms." It just knows whether it's true or false, and in this case, if you provide arguments that don't have a common type that they implicitly convert to, then the template constraint will fail. But ultimately, you're going to have to read the template constraint and figure out why the arguments are failing. - Jonathan M Davis
Jan 28
parent reply welkam <wwwelkam gmail.com> writes:
On Sunday, 28 January 2018 at 20:42:52 UTC, Jonathan M Davis 
wrote:
 There is nothing incorrect about the error message. The 
 compiler looked at all of the functions in the overload set, 
 and it found none that matched. The reason that it found none 
 that matched was because it couldn't find any function template 
 where those arguments passed the template constraint, and it 
 tells you so.

 So, there is no bug here in the sense that the compiler is 
 telling you the wrong thing. You can certainly open a bug 
 report arguing that the error messages isn't human-friendly 
 enough and suggest alternatives, and something along those 
 lines may be implemented, but the message isn't actually wrong. 
 So, feel free to open a bug report.

 However, you're not going to get an error message that says 
 anything like "the arguments aren't the same type." The 
 compiler doesn't understand what the template constraint means 
 in "human terms." It just knows whether it's true or false, and 
 in this case, if you provide arguments that don't have a common 
 type that they implicitly convert to, then the template 
 constraint will fail. But ultimately, you're going to have to 
 read the template constraint and figure out why the arguments 
 are failing.

 - Jonathan M Davis
I would not complain if there were multiple functions just like error said. But the set contains only one making it not a set anymore and it says nothing about constraints. I downloaded dmd source. Might figure out something myself tomorrow
Jan 28
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 28, 2018 at 10:53:39PM +0000, welkam via Digitalmars-d-learn wrote:
 On Sunday, 28 January 2018 at 20:42:52 UTC, Jonathan M Davis wrote:
[...]
 However, you're not going to get an error message that says anything
 like "the arguments aren't the same type." The compiler doesn't
 understand what the template constraint means in "human terms." It
 just knows whether it's true or false, and in this case, if you
 provide arguments that don't have a common type that they implicitly
 convert to, then the template constraint will fail. But ultimately,
 you're going to have to read the template constraint and figure out
 why the arguments are failing.
[...] Well, that's not *quite* true. The compiler *does* have enough information to be able evaluate the constraints, for one. So in theory it *should* be able to identify which constraint(s) failed. Some time ago there was a push to refactor Phobos sig constraints in CNF (conjunctive normal form), which would simplify this somewhat: if a function has sig constraints X, Y and Z, and Y evaluated to false, then the compiler could print condition Y as the cause of failure. Furthermore, the reason for the perceived unhelpful message is more subtle. It's because a sig constraint amounts to a limitation in scope of a particular overload, effectively saying "this overload only applies if conditions X, Y and Z are true". So a failure in one or more sig constraints isn't necessarily a *problem* per se; it just means that particular overload declines instantiation to the rest of the overload set. Only if the failure ultimately leads to a failure to match *all* overloads, can we say for sure that the failed constraint was the "cause" of the mismatch. And this is where things get tricky, because if you have an overload of, say, 10 members, then obviously a failure to find a match means that *every* overload had its sig constraints fail one way or another. But without being able to read the programmer's mind, the compiler has no idea which overload was the *intended* target of the function call; so it would not be able to tell which failed sig constraint was the most relevant to the user. All >=10 failed conditions would have to be displayed, and it would be up to the user to decide which one is the relevant one. Of course, even in spite of this, displaying the failed conditions is still better than nothing. If the compiler assumes CNF on sig constraints, then it can list, along with each candidate overload, the failing term(s) in the CNF for that particular overload as the reason that overload wasn't chosen. For example, the output could be something like: Error: unable to match func() with argument type X; candidates are: std/range/package.d(100): auto func(R)(R r) if (isInputRange!R && is(ElementType!R == char): condition is(ElementType!R == char) failed std/range/package.d(200: auto func(R)(R r) if (isForwardRange!R && is(ElementType!R : int): condition isForwardRange!R failed std/range/package.d(300): auto func(E)(E[] arr): X does not match parameter type E[] You'd still have to parse through each listed overload, but at least the compiler would tell you which sig constraint failed. IME, this would be helpful, because sometimes it's not at all obvious which sig constraint failed, especially if the sig constraints call upon other templates to test the incoming type (e.g., isInputRange, which contains a whole bunch of tests, any of which could fail and it's not always obvious which ones), and I wind up having to parse through *all* sig constraints of *all* overloads just to figure out which one was the real cause.
 I would not complain if there were multiple functions just like error
 said.  But the set contains only one making it not a set anymore and
 it says nothing about constraints.
[...] This topic has come up again numerous times, and I think *some* improvement on this front is necessary. One improvement is to decrease our reliance on overloads, and to use more permissive sig constraints with static ifs inside the function body that can provide a more helpful error message. Not to mention, some of the current Phobos overloads are divided based on implementation details user code shouldn't need to know about, rather than *logical* overload boundaries, for example: // handle the case when S is a string auto func(R,S)(R haystack, S needle) if (isInputRange!R && isSomeString!S) ... // handle the case when S is an array but not a string auto func(R,S)(R haystack, S needle) if (isInputRange!R && !isSomeString!S && isArray!S) ... This is leaking implementation details into the sig constraints; it really should be written this way instead: auto func(R,S)(R haystack, S needle) if (isInputRange!R) { static if (isSomeString!S) ... // handle the case where S is a string else static if (isArray!S) ... // handle the case where S is an array but not a string else // Helpful message if implementation doesn't // support the incoming type static assert(0, "S must be either a string or an array"); } This way, there's (1) a smaller number of overloads the user needs to parse through when an error occurs; (2) when an error occurs, it's obvious that the failing condition is isInputRange!R: the user only needs to figure out 1 sig constraint as opposed to 4 to find the problem; and (3) the else-clause of an internal static if can be used to provide more user-friendly error messages, if the argument is an input range, but not of a kind the current implementation supports. I'd even venture to say that this applies not just to Phobos but to template code in general. Personally, I go by the rule that the sig constraints should be general, and should document what the user would logically understand the function parameters ought to be (i.e., the parameter must be an input range). Anything else, like handling various specializations (do X if the element type is char, do Y if it's a POD, etc.) should be done inside the function body, away from the public-facing sigs. If the current implementation doesn't handle all of the types that the function logically should, then the else-clause of the internal static if can be used to provide a more user-friendly error message explaining why the passed-in type doesn't work. T -- We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL
Jan 28
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Sunday, January 28, 2018 16:08:17 H. S. Teoh via Digitalmars-d-learn 
wrote:
 On Sun, Jan 28, 2018 at 10:53:39PM +0000, welkam via Digitalmars-d-learn 
wrote:
 On Sunday, 28 January 2018 at 20:42:52 UTC, Jonathan M Davis wrote:
[...]
 However, you're not going to get an error message that says anything
 like "the arguments aren't the same type." The compiler doesn't
 understand what the template constraint means in "human terms." It
 just knows whether it's true or false, and in this case, if you
 provide arguments that don't have a common type that they implicitly
 convert to, then the template constraint will fail. But ultimately,
 you're going to have to read the template constraint and figure out
 why the arguments are failing.
[...] Well, that's not *quite* true. The compiler *does* have enough information to be able evaluate the constraints, for one. So in theory it *should* be able to identify which constraint(s) failed. Some time ago there was a push to refactor Phobos sig constraints in CNF (conjunctive normal form), which would simplify this somewhat: if a function has sig constraints X, Y and Z, and Y evaluated to false, then the compiler could print condition Y as the cause of failure.
Sure, work could be done to indicate which pieces of a template constraint are true and which are false, but the point still stands that it can't actually tell the programmer what that means in "human terms." The intent isn't there. Now, that's why there have been suggestions for doing stuff like providing error strings to go with template constraints that can be displayed on failure, but ultimately, the compiler can't read the programmer's mind.
 Of course, even in spite of this, displaying the failed conditions is
 still better than nothing.  If the compiler assumes CNF on sig
 constraints, then it can list, along with each candidate overload, the
 failing term(s) in the CNF for that particular overload as the reason
 that overload wasn't chosen.
IMHO, that's doomed to failure unless the compiler somehow requires that the template constraints be in CNF, which would be really annoying in its own right. The most practical thing at this point is to intelligently use traits with useful names in template constraints and to simplify the constraints as much as possible, with the overloading primarily done internally with static ifs - like you like to point out, and we've done some of that to Phobos, but there's a lot of work left to be done there. Still, I think that it's always going to be the case on some level that the programmer is going to have to look at template constraints and figure out why they're failing, even if we do manage to improve how much information is given about which parts are failing. - Jonathan M Davis
Jan 28