Now that's a DIP that could use some love
H. S. Teoh
hsteoh at quickfur.ath.cx
Thu Sep 17 19:58:45 UTC 2020
On Thu, Sep 17, 2020 at 01:16:13PM -0600, Jonathan M Davis via Digitalmars-d wrote:
> Honestly, IMHO, that makes the code far worse. You're just repeating
> the constraints in plain English, which requires more than double the
> code for each constraint and doesn't really make the error messages
> much easier to understand IMHO - especially when the constraints are
> already using traits that make what they're doing clear.
> It's like commenting every line to say what it does.
Exactly, this breaks DRY.
> And as Adam pointed out, the problem is usually in figuring out why a
> particular constraint is failing, not what a constraint means, and
> that has a tendency to result you having to do stuff like copy the
> constraint into your code and breaking it apart to test each piece and
> then potentially digging into the traits that it's using (such as
> isInputRange) to figure out why that particular trait is true or
That's totally been my experience with writing heavy range-based UFCS
code. These days, thanks to recent efforts to improve error messages,
the compiler will now come back with "no matching overload: must satisfy
constraints: X, Y, Z". Which is a good start; however, it doesn't go
far enough, because these days Phobos sig constraints are opaque:
auto somePhobosFunc(R)(R r)
if (isInputRange!R && satisfiesX!R && satisfiesY!R && ...)
The compiler tells me my argument fails the constraint `satisfiesX!R`,
but `satisfiesX` is an internal Phobos helper template; I have no idea
what it's checking for and why my argument fails to satisfy it. At the
end of the day, I have to go digging into Phobos code, copy-n-paste it
into my own, then eliminate the failing conditions one by one, just like
Instead of this half-baked hack of essentially writing comments that
repeat what the code already says, what we should be doing is to take
the current error messages one step further: when some clause in a sig
constraint fails, how about the compiler ungags the errors that cropped
up while evaluating that clause? Instead of blindly ungagging
*everything* (*cough*-verrors=spec*cough*), which results in a deluge of
irrelevant errors that the one relevant message gets lost in, ungag only
the most likely relevant errors: the ones produced when evaluating a
failed sig constraint clause.
I think that would improve error messages much more than the
repeat-after-yourself exercise proposed here.
Obviously, some things aren't very obvious.
More information about the Digitalmars-d