On 5/15/17 1:16 PM, Stanislav Blinov wrote:
On Monday, 15 May 2017 at 15:30:38 UTC, Steven Schveighoffer wrote:
Argument 2 is a string, which is not supported
file(line): Error: template foo cannot deduce function from argument
types !()(int, string), candidates are:
file(line): foo(Args...)(auto ref Args arg) if (noStringArgs!args)
I think the compiler should be able to figure this out, and report it.
The if constraint is a boolean expression, and so it can be divided
into the portions that pass or fail.
How? The constraint, any constraint, is de-facto user code.
Code evaluated at compile time. It actually has to evaluate each of the
pieces, and knows why the whole if statement fails exactly.
The constraint:
void foo(T)(T t) if (cond1!T && cond2!T && cond3!T), the compiler knows
both what each of those terms evaluate to, and therefore which ones are
causing the thing not to be enabled.
Even in the
simple example I've provided, I would not expect the compiler to figure
out what are *my* expectations on the types.
I think you misunderstand, your example would still not compile, and
instead of "here are all the ones I tried", it's "here are all the ones
I tried, and in each case, I've highlighted why it didn't work".
Many times, you can figure out by looking at the constraints why it
didn't work. However, I've encountered many cases where it's saying it
doesn't pass isSomeDoodad!T when I thought T is a doodad. Then I need to
figure out why it's not working.
Even your library code cannot be all-knowing about what the calling user
is trying to do. It may be confusing to him as well. But just "here's a
giant if statement, I as the compiler have figured out why it's not
true, see if you can too!" is crap.
Even if the compiler was to divide the constraint into blocks and reason
about them separately,
It is.
it's still limited to error reporting we have
now: it will report "is(T == string) was expected to be false, but it's
true". Is that a good error message?
Yes. It's a perfect error message actually. What is confusing about it?
What I'd love to see is the constraint colorized to show green
segments that evaluate to true, and red segments that evaluate to
false. And then recursively show each piece when asked.
I think any time spent making a user-level solution will not scale.
The compiler knows the information, can ascertain why it fails, and
print a much nicer error message. Plus it makes compile-time much
longer to get information that is already available.
I don't see how that is possible. The constraints' complexity is
arbitrary, it's semantics are arbitrary. The compiler does a full
semantic pass, we end up with the error messages as if it was normal
program code. But the thing is, we need different error messages,
because it isn't "normal" program code.
It has to know. It has to evaluate the boolean to see if it should
compile! The current situation would be like the compiler saying there's
an error in your code, but won't tell you the line number. Surely it knows.
Imagine also a constraint like isInputRange!R. This basically attempts
to compile a dummy lambda. How would one handle this in user-code?
Umm... Exactly as it is implemented currently? With one important
distinction that I would be able to report *exactly why* the type in
question does not satisfy the constraint. Not an obscure
"Error: no property 'empty' for type (typename)"
"Error: expression 'foo.front()' is void and has no value"
but a descriptive
" Argument <number> does not satisfy the constraint isInputRange:"
"(typename) is expected to be an input range, but it doesn't implement
the required interface:"
" property 'empty' is not defined."
" property 'front' is defined, but returns void."
The first would be great. I'm having trouble really seeing a reason to
prefer the second over the first, it's just a verbose description of the
same thing.
Today we get an error that:
void foo(R)(R r) if(isInputRange!R)
doesn't compile for the obvious (to you) range type R. What it doesn't
tell you is anything about why that doesn't work. We don't even get the
"no property empty" message.
Let me give you a real example. The isForwardRange test used to look
like this:
template isForwardRange(R)
{
enum isForwardRange = isInputRange!R && is(typeof(
(inout int = 0)
{
R r1 = R.init;
static assert (is(typeof(r1.save) == R));
}));
}
Here is the definition of isInputRange:
template isInputRange(R)
{
enum bool isInputRange = is(typeof(
(inout int = 0)
{
R r = R.init; // can define a range object
if (r.empty) {} // can test for empty
r.popFront(); // can invoke popFront()
auto h = r.front; // can get the front of the range
}));
}
Simple, right? However, this was the situation before I applied a fix:
struct ForwardRange
{
int front() { return 1; }
void popFront() {}
enum empty = false;
ForwardRange save() { return this; }
}
static assert(isInputRange!R);
static assert(!isForwardRange!R);
You tell me, what is the issue? Having library-writer defined error
messages are not going to help there because I didn't do it *exactly* right.
If you aren't sure what the answer is, here is the PR that fixed it:
https://github.com/dlang/phobos/pull/3276
User code can collect all the information and present it in a readable
way. Compiler will never be able to. The best the compiler would do is
report "T does not satisfy isInputRange". And in my opinion, that is
what it should do. Adding complexity to the compiler to figure out all
imaginable variations doesn't seem like a very good idea. User code is
able to make all assessments it needs, it just doesn't have the ability
to elaborate.
No, the compiler just needs to detail its evaluation process that it's
already doing.
If the constraint doesn't actually match the pragma message, you get
MISLEADING messages, or maybe messages when it actually compiles. Much
better to have the compiler tell you actually what it's doing.
Another example:
is(typeof(x) == string) && x.startsWith("_")
The best we can expect from the compiler is print that out and say it
evaluated to false.
It can say that is(typeof(x) == string) is false, or x.startsWith("_")
is false.
User code, on the other hand, can generate a string "x must be a string
that starts with an underscore". Which one is better?
My version. Is x not a string, or does x not start with an underscore?
Not enough information in your error message. And it doesn't give me
more information than the actual constraint code, it's just written out
verbosely.
-Steve
