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.
