A proposal for better template constraint error reporting.

[Jonathan M Davis]

On Wednesday, October 26, 2011 10:26 Gor Gyolchanyan wrote:
> I agree. But how to address the template constraint problem then?

It's a completely separate issue. Being able to add comments which appear in 
template constraint messages would definitely be valuable (though using 
functions or eponymous templates with descriptive names - such as 
isForwardRange - mostly fixes the problem) and may very well be worth adding. 
But it would be all or nothing, whereas your proposal seems to assume that 
it's possible to give a message based on which part of the template constraint 
failed. However, at this point, as far as the compiler is concerned either a 
template constraint succeeds or fails. It doesn't try and figure out which 
parts succeeded or failed, and I suspect that for it to do so would definitely 
complicate matters. Still, printing out the whole template constraint with 
comments included could be valuable.

Of greater concern IMHO is the fact that it's always the first template 
constraint which is given. You could have 10 different overloads of the same 
template with you trying to use the 7th one, and the error message prints only 
the first template constraint, even if it really has nothing to do with your 
problem. But I really don't know how to fix that. It can't possibly know which 
overload you were actually targetting. All it knows is that none of the 
template constraints passed. And printing out _all_ of the template 
constraints could get very messier (e.g. think of what you'd get with 
std.conv.to if you printed out _all_ of the template constrainst for toImpl). 
The way that I've taken to solving the problem is to create one template which 
covers _all_ of the cases for that template and has an appropriate template 
constraint, and then have a template that _it_ uses which has all of the 
appropriate overloads, and that more or less solves the problem, but it would 
be nice if we could find a better solution for it such that the compiler can 
give better error messages on its own.

Overall, I'd say that your suggestion has merit, but I don't think that it's 
going to work quite as you envisioned. It would probably also be simpler if it 
were a single comment for the whole constraint (particularly given that it 
can't give you only one message from inside the constraint anyway), but I 
don't know.

- Jonathan M Davis