Now that's a DIP that could use some love

[Jackel]

On Monday, 14 September 2020 at 15:28:29 UTC, Andrei Alexandrescu 
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.

Don't like that syntax at all. If statements aren't assert 
statements. No where else is an if statement used in that manor, 
worse so in that that would have actually been valid were the 
comma expression still accepted. So it is the same syntax with 
different meaning.

For your example with "max", the reason there isn't a good error 
message for that, depending on what you pass to it. Is that 
"MaxType" doesn't check if the type passed in has a ".max" 
variable/component. So that's where it errors and it isn't 
handled properly. The template could be changed to ensure that 
the type being passed in is numerical, which it currently doesn't 
but the way it functions seems to assume that it is. Ultimately 
how code is written is going to affect the readability more so 
than adding more features.