A proposal for better template constraint error reporting.

[Gor Gyolchanyan]

Good points. I think if we add the notion of a predicate to D, things
would change dramatically.
Predicates would become the primary subject of such features, as:
* template constraints
* invariants
* in and out contracts
* unittests
* any other assertions and checks
* overloading
* conditional statements

The predicates would always have a message of failure integrated, so
any time a predicate fails a message is always available to either
throw as an exception, or display as a compile-time error or log in a
file for any reason.
The key point is, that anything, that ends up as a bool is a predicate.

On Wed, Oct 26, 2011 at 10:41 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> 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
>