Now that's a DIP that could use some love
H. S. Teoh
hsteoh at quickfur.ath.cx
Fri Sep 18 04:55:08 UTC 2020
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.
Don't throw out the baby with the bathwater. Use your hands...
More information about the Digitalmars-d