On the subject of error messages

[Stanislav Blinov via Digitalmars-d]

On Monday, 15 May 2017 at 19:44:11 UTC, Steven Schveighoffer 
wrote:
> 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.

Yes, that is what it is: code. Code that follows language rules, 
not some ADL. No mater how expressive the language is, it is 
still code. And if, on compile error, the compiler shows me the 
code from the foreign library that I thought I was using 
correctly, I'm supposed to now do what the compiler just did and 
figure out where I made a mistake.

>> 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". [...]
> [...] Then I need to figure out why it's not working.

It is exactly for the cases where the logic is more complex than 
a simple test that my proposal is for. I'm not suggesting to 
abuse it throughout.

>> 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?

There is no context. To get at context, I have to look at the 
code.

>> 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.

It "knows" it evaluated false. It doesn't know how to give user a 
digestible hint to make that false go away.

> 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.

Exactly my point.

> Let me give you a real example. The isForwardRange test used to 
> look like this:
>
> template isForwardRange(R)

I'm going to need to digest that.


> No, the compiler just needs to detail its evaluation process 
> that it's already doing.

That is not enough. Failure may be X levels deep in some obscure 
chunk surrounded by static ifs and and a bunch of wonky tests 
involving attempted lambda compilations (which I'd have to parse 
and "compile" in my head in order to try to understand what 
failed).

> 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.

The library author is free to take as many passes over their 
messages as they deem necessary. They can be as vague or as 
precise as needed. It is their responsibility.

>> 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.

I've already demonstrated that the message text can be made as 
precise as is required for a concrete use case, there's no need 
to nitpick ;) I could as easily report either:

"x is not a string"

or

"string x should start with an underscore".

or

"Argument 10 (int) is not a string. This method is only callable 
with strings that start with an underscore".

"Value of argument 10 (string) does not start with an underscore. 
This method is only callable with strings that start with an 
underscore".

I, as a responsible author, can decide what amount of information 
must be presented. It could be accompanied by code, I'm not 
against that. The main point is to explain the error without 
*requiring* the user to use their head as a compiler.