Looks like wrong error message

[Jonathan M Davis]

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