Now that's a DIP that could use some love

Jonathan M Davis newsgroup.d at
Thu Sep 17 19:16:13 UTC 2020

On Monday, September 14, 2020 9:28:29 AM MDT Andrei Alexandrescu via 
Digitalmars-d wrote:
> Yes, indeed the recent improvements are noticeable. On a synthetic
> example it looks all dandy, but clearly there's be a large improvement
> by allowing semantic error messages. I just happened to have
> std.algorithm.comparison opened and here are a few examples:
> template among(values...)
> if (isExpressionTuple!values, "All values in the among expression must
> be expressions")
> auto max(T...)(T args)
> if (T.length >= 2)
> if (!is(CommonType!T == void), "Types "~T.stringof~" don't have a common
> type for choosing the maximum.")
> (similar for min)
> CommonType!(T, Ts) either(alias pred = a => a, T, Ts...)(T first, lazy
> Ts alternatives)
> if (alternatives.length >= 1, "Need at least one alternative besides
> primary choice")
> if (!is(CommonType!(T, Ts) == void), "Types "~AliasSeq!(T,
> Ts).stringof~" need a common type")
> if (allSatisfy!(ifTestable, T, Ts), "Types "~AliasSeq!(T, Ts).stringof~"
> must be testable with the if (...) statement")
> Better error messages are always a good investment.

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.

Having the compiler indicate which parts of a constraint are true or false
could be useful, and I'm sure that we could improve the error messages, but
I think that there's a problem if we're having to put a bunch of English
text into the constraints to explain what's going on - especially when it's
generally just going to be saying the same thing as the code except in
English. It's like commenting every line to say what it does.

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. I have a lot of trouble
believing that translating stuff into English text is going to actually help
in practice. In some cases, it might help someone who really isn't familiar
with how traits and template constraints work, but for someone familiar with
D code, I would expect it to just be redundant and that it wouldn't help
with the actual problem. It also has the problem that comments can have in
that if you're not careful, the code and message may not match up later on
as the code is maintained.

I really think that we should be looking at how we can get the compiler to
give us better information and reduce how much we have to do stuff like copy
the constraint and test out its parts separately from the template if we
want to make dealing with template constraints easier.

- Jonathan M Davis

More information about the Digitalmars-d mailing list