Unhelpful error messages

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Jul 8 11:09:10 PDT 2013


On Sun, Jul 07, 2013 at 02:06:46PM +0200, Peter Alexander wrote:
[...]
> The problem here is more general than this specific case. Any
> template constraint on any function could fail to pass, and the best
> error you'll get is that it couldn't match any function. Even if the
> error messages were improved to tell you what part of the constraint
> failed, you still have no idea *why* it failed (e.g. *why* is my
> range not a forward range?)
> 
> Overloads just make matters exponentially worse. Not only can the
> compiler fail to provide a good error for a single function, but
> needs to provide a good error for every possible candidate function.
> If a constraint checks if another overloaded function is callable
> then you end up with a combinatorial explosion of reasons why your
> function didn't compile.
> 
> It's a tough situation and I think the only way this could even
> reasonably be resolved is through some sophisticated IDE
> integration. There is no way to display this kind of error report in
> a blob of command line text.

I don't see how an IDE could do better than the compiler. Combinatorial
explosion is a nasty problem, and if an IDE could solve it, so could the
compiler. Sure, the IDE could give you a nice scrollable GUI widget to
look through all the various reasons of the instantiation failure, but
fundamentally speaking, that's not much different from running grep
through 50 pages of compiler output. You still haven't solved the root
problem, which is to narrow down the exponential set of possible problem
causes to a manageable, human-comprehensible number.

I think the crux of the problem is that there's no reasonable way to
tell the difference between toImpl!(float)'s signature constraint
declining a particular instantiation because you're trying to convert a
struct, vs. toImpl!(struct)'s signature constraint declining it because
the struct causes compile errors.

If toImpl!(struct) accepted *all* struct instantiations, then when a
compile error occurs it would be much easier to track it down to a
problem with the struct. You'd know that toImpl actually supports
converting a struct, but due to the struct's non-conformance to some
requirements, this particular attempt failed. You'd be able to pinpoint
the problem to the struct immediately, rather than wondering whether the
problem was that toImpl doesn't support struct conversions.

But by rejecting all non-compiling types (including structs) outright,
it's basically pushing the problem up to the level of which of the 25
overloads of toImpl should be chosen for this particular instantiation
-- 24 overloads of which have nothing whatsoever to do with structs.
That's where the combinatorial explosion comes from.


T

-- 
Computers aren't intelligent; they only think they are.


More information about the Digitalmars-d mailing list