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?
