On the subject of error messages

[Steven Schveighoffer via Digitalmars-d]

On 5/15/17 8:14 PM, Stanislav Blinov wrote:
> On Monday, 15 May 2017 at 20:55:35 UTC, Steven Schveighoffer wrote:
>> On 5/15/17 4:24 PM, Stanislav Blinov wrote:
>>> On Monday, 15 May 2017 at 19:44:11 UTC, Steven Schveighoffer wrote:
>>
>>>> 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.
>>
>> I'm going to snip away pretty much everything else and focus on this.
>>
>> The compiler absolutely 100% knows, and can demonstrate, exactly why a
>> template constraint failed. We don't have to go any further, or make
>> suggestions about how to fix it.
>
> In complex constraints, that is not enough. When we have loops (i.e.
> over arguments, or over struct members), would it report the
> iteration/name?

Yes.

> Would it know to report it if `false` came several
> levels deep in the loop body?

Yes.

> Would it know that we actually *care*
> about that information? (*cough* C++ *cough* pages and pages of error
> text because of a typo...)

The idea is to give a preliminary rough report of which part of a 
boolean expression caused it to evaluate to false. Then you recompile 
with a flag to tell the compiler to do a deeper dive.

> When we have nested static ifs, it's important to see, at a glance,
> which parts of the combination were false. Again, if they're several &&,
> || in a row, or nested, pointing to a single one wouldn't in any way be
> informative.

Why not?

> When we have tests using dummy lambdas, are we to expect users to
> immediately extract the lambda body, parse it, and figure out what's wrong?

This is what you have to do today. The task has already been tried by 
the compiler, and the result is known by the compiler. Just have the 
compiler tell you.

>> Just output what exactly is wrong, even if you have to recurse into
>> the depths of some obscure template isXXX, and all it's recursively
>> called templates, I can get the correct determination of where either
>> my type isn't right, or the constraint isn't right.
>
> Please look over my isMovable example (I'm not sure if you caught it, I
> posted it as a follow up to my other reply). Suppose the `false` is
> pointed at by the compiler:
>
>>    else static if (is(T == struct) &&
>>            (hasElaborateDestructor!T || hasElaborateCopyConstructor!T)) {
>>        foreach (m; T.init.tupleof) {
>>            static if (!isMovable!(typeof(m)) && (m == m.init)) {
>>                return false;
>>                       ^
>>                       |
>>            }
>>        }
>>        return true;
>>    } else
>
> That is very, *very* uninformative. I don't know which member it was, I
> don't know which part of the conditional was false. I don't know which
> part of the conditional further up was true. Would the compiler know to
> tell me all that? Would it know to test further, to collect *all*
> information, so that I don't have to incrementally recompile fixing one
> thing at a time?

The compiler, and by extension your hand-written error checking, cannot 
know the true intention of the user. All it knows is you tried to do 
something that isn't supported. You have to figure out what is wrong and 
fix it. If that takes several iterations, that's what it takes. There is 
no solution that will give you all the answers.

In your example, the compiler would point at isMovable!S as the issue. 
Not super-informative, but is all it gives to prevent huge outputs. Then 
you tell it to print more information, and it would say that false was 
returned when the m member of type T is being checked, at which point 
you could get a stack trace of what values were at each level of 
recursion. Everywhere a boolean evaluated to true in order to get to the 
point where false is returned would be colored green, every time it was 
false, it would be colored red, and every time a short circuit happened, 
it wouldn't be colored.

For checking to see that "something compiles", it could identify the 
code that fails to compile. Again, the compiler has all this information.

This isn't any harder than debugging, in fact it should be easier, as 
all the compiler metadata is available in memory, and most of the 
information can be conveyed without having to poke around.

And it should be just about as good as your hand-written message. But 
always accurate, and instantly available to all existing constraints.

> Most importantly, as a user who sees this for the first time, I'd have
> no idea *why* those checks are there. I'd have no context, no grounds to
> base my reasoning on, so I'd either have to jump back to docs to see if
> I missed a corner case, or start spelunking code that I didn't write,
> which is always so fun... Thing is, the compiler is exactly in that
> position. It doesn't read the docs, ever :) It's always spelunking code
> written by someone else. It can't tell what the constraint, as a unit,
> is *actually* testing for. It doesn't care that we shouldn't
> destructively move structs with const members. So it wouldn't be able to
> tell me either. All it will do is report me that that false was returned
> on that line, and (hopefully), some additional info, like member type
> and name.

We can't hand-hold everyone. At some point you have to learn programming 
and debugging :)

-Steve