Simple and effective approaches to constraint error messages

[Steven Schveighoffer via Digitalmars-d]

On 4/25/16 6:14 PM, H. S. Teoh via Digitalmars-d wrote:
> On Mon, Apr 25, 2016 at 05:20:08PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
>> On 4/25/16 1:52 PM, Andrei Alexandrescu wrote:
>>> It's been long asked in our community that failing template
>>> constraints issue better error messages. Consider:
>>
>> I like the first option. However, I think it should be deeper than
>> that.
>>
>> Sometimes you have code that you are sure matches one of the
>> constraints (e.g. isInputRange), but for some reason it doesn't. Sure,
>> it's good to know that your struct that looks exactly like an input
>> range isn't an input range, but to know why would be better.
>>
>> I realize that more context for an error may be too verbose, but an
>> option to have the compiler tell you exactly why it is stopping
>> compilation is good when you can't figure out the obvious reason.
>
> What about displaying the full context with -v? The compiler currently
> already uses -v to show long error messages that are truncated by
> default.

Sure, but the problem is that -v enables a TON of messages. I'd 
definitely be willing to deal with that if that's the only way to show it.

>> So for instance, having it say "constraint failed:
>> isInputRange!NotARange" is good, but if you pass some parameter it
>> says something like: "constraint failed: isInputRange!NotARange,
>> std.range.primitives:146 failed to compile: x.front
> [...]
>
> What about this: when a constraint fails, display the first (related
> group of) error messages related to that constraint that the compiler
> would have emitted if errors weren't gagged. So if isInputRange fails to
> instantiate for some argument, the compiler would show the first error
> message that resulted in template instantiation failure, e.g.:
>
> 	std/range.d(123): Error: no property 'front' for type 'int'

Absolutely, that's what I'm looking for.

One thing that I remember being an issue with isXRange (can't remember 
which one) is that it required is(typeof(r.front) == ElementType!R), 
which looks innocuous enough. However, for ranges where front is a 
method, but is not labeled @property, this fails. This has since been fixed.

Someone who makes such a range, and then sees it failing because of some 
obscure compiler behavior is almost certainly never going to figure this 
out without an in-depth investigation. Having the compiler just tell 
them the answer is sooo much better.

-Steve