On the subject of error messages

[Stanislav Blinov via Digitalmars-d]

On Tuesday, 16 May 2017 at 14:00:51 UTC, Nick Treleaven wrote:
> On Tuesday, 16 May 2017 at 11:20:57 UTC, Stanislav Blinov wrote:
>> On Tuesday, 16 May 2017 at 09:04:32 UTC, Nick Treleaven wrote:
>>> The problem with this approach is all the work required to 
>>> convert existing code to use this style.
> ...
>> That's not a problem. In cases where compiler-provided 
>> diagnostic is sufficient, nothing will need to be done.
>
> I don't understand. I thought you were proposing a new language 
> feature (constraint expressions or pragma(overloadError))?

Oh. What I am proposing is add the possibility for the 
constraints to return a string in addition to the boolean. I am 
*not* proposing to remove the existing boolean checking. The 
compiler knows what type the constraint returns. If it's a 
boolean, nothing is changed. If it's a tuple, it could use the 
second value as a message (when it needs to output a message, 
i.e. when all overloads failed). pragma was just presented as an 
alternative. That's it :) Existing code should not break.

> My priority is (1) For the compiler to show which part of a 
> constraint failed. Having inline constraints is lower priority, 
> except:

 From a user perspective, I would be interested in what the 
constraint failure *means*, not which part of it returned false. 
The constraint is there to prevent me from calling the function 
with the wrong types of arguments. The author decided which types 
are wrong. How the author checks for that is their business. 
Simply telling me I'm wrong does not help me stop being wrong. 
Showing me the "evidence" (constraint code) does not help me 
either, because the evidence is arbitrary, and in this case is a 
process, not statement of fact.

Steven argues that the compiler should be able to show the cause 
of failure. My counter-argument is that it's not helpful, because 
an isolated piece of the constraint does not necessarily reflect 
it's intent. Diagnostic generated from arbitrary code written by 
the constraint author will be even more confusing than telling 
nothing at all. Because it is code not written by the user, it 
may use names not provided by the user, etc. If I wrote a call 
foo(x), and then compiler tells me:

'property bar.front' is not defined

I'm going to take offense. I didn't pass any 'bar' to that 
function. Yet it's there because whoever wrote the constraint 
used a lambda there to test for something. Now I'd have to look 
at that, figure out what that 'bar' is, etc... Why should I? Why 
can't the constraint cleanly report what it's "false" result 
actually means?