Now that's a DIP that could use some love

[H. S. Teoh]

On Thu, Sep 17, 2020 at 08:43:02PM -0600, Jonathan M Davis via Digitalmars-d wrote:
[...]
> What I need to know is _why_ my arguments are not meeting the function
> template's requirements. And unless that's really obvious by just
> glancing at the code, because I made a simple and obvious mistake,
> that probably means that I'm going to have to copy the template
> constraint into my own code and test each piece individually to see
> which pieces are true and which are false. And once I know that, I may
> have to dig deeper and go inside the traits that were used in the
> template constraint and copy their contents into my code so that I can
> check each piece individually to see what's true and what's false so I
> can figured out where the problem is.

Yes, and *this* is the crux of the issue here.  Get this right, and the
rest is just cosmetic cleanup.  Get this wrong, and no matter how many
cosmetics you pile on, it's still a carcass.

This is why I suggested that the compiler should ungag errors for the
constraint clause that failed to be met.  *That* would be a lot more
useful because it will actually tell me what went wrong, instead of
papering over it with some generic abstract message that, as Jonathan
says, I should have already known before calling the function.

Quite often, when there's a typo or some kind of bug in my code, the
error comes in the form of some lambda or range failing to meet some sig
constraints of a Phobos function.  The sig constraint may be checking
that something is a forward range.  I *already* know that the function
is expecting a forward range; and I wrote the UFCS chain believing that
the resulting of the preceding part of the chain returns a forward
range, and now it comes back and says "function XYZ expects a forward
range".  Well no kidding, I already knew that.  What I need to know is,
*why* is the preceding part of the UFCS chain *not* a forward range when
I expected it to be one?  For this, I want to see what exactly about a
forward range's requirements I failed to meet. Was it because I left out
.save again?  Or was it because I had a typo and .front doesn't compile,
so it failed to qualify as a forward range?

Currently, these failures are gagged, and the compiler substitutes in
its place "argument must satisfy constraint: isForwardRange!R", which is
of no help.  Even if this were replaced with a hand-written message (in
Queen's English, no less), it would still be of no help.  Just stop
dithering about, and TELL ME THE DARNED COMPILE ERROR DAMMIT!!!!!  I'm a
programmer; I won't get scared by messages like "syntax error in
myRange.front: no such identifier 'xyz'".  Or "cannot call .front from
@safe code because it escapes a reference to member .zzz".  In fact,
these are the very errors that will actually tell me what I need to fix
in my code.  These are the errors that I *want* to see.

Substituting these "ugly" errors with some veneer of Queen's English is
no different from "argument must satisfy constraint: isForwardRange!R",
which essentially amounts to "hahaha your range fails to be a forward
range, and ninner-ninners, I'm not gonna tell you why!".


[...]
> If the compiler is going to make life easier when a template
> constraint fails, then it needs to be giving information about what
> specifically in the constraint is true and false so that you don't
> have to copy it into your code and compile it to figure it out.
> Additionally, when it gags an error within a template constraint, it
> would be useful to know what it gagged so that you don't have to copy
> the pieces out to get that information. And all of that relates to
> understanding the actual template constraint, what exactly it's
> testing, and exactly which pieces are failing, not the abstract
> concept that a message in English would provide.

Exactly.


T

-- 
Don't throw out the baby with the bathwater. Use your hands...