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
