Now that's a DIP that could use some love

[H. S. Teoh]

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
> false.
[...]

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
Jonathan says.

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.


T

-- 
Obviously, some things aren't very obvious.