On the subject of error messages

[Stanislav Blinov via Digitalmars-d]

Let's suppose I wrote the following template function:

>import std.meta;
>
>enum bool isString(T) = is(T == string);
>
>void foo(Args...)(auto ref Args args)
>if (!anySatisfy!(isString, Args)) {
>    // ...
>}

This one is variadic, but it could as well have been 
non-variadic. The important
aspect is that it has a constraint. In this case, the constraint 
is that it should
accept any argument types *but* strings.

Now, if I call it with a string argument:

>foo(1, "a");

I get the following error:

>file(line): Error: template foo cannot deduce function from 
>argument types !()(int, string), candidates are:
>file(line): foo(Args...)(auto ref Args arg) if 
>(!anySatisfy!(isString, Args))

Ok, so the call does not compile, but the message is rather 
vague: it doesn't
tell me which argument(s) failed to satisfy the constraint.
In this simple example it's easy to see where the error is, but 
if foo() was
called in a generic way (i.e. arguments come from somewhere else, 
their type
determined by inference, etc.), or if the constraint was more 
complex, it
wouldn't be as easy to spot.

So, to help with this, let me write a checker and modify foo's 
signature, thanks
to CTFE:

>template types(args...) {
>    static if (args.length)
>        alias types = AliasSeq!(typeof(args[0]), 
> types!(args[1..$]));
>    else
>        alias types = AliasSeq!();
>}
>
>auto noStringArgs(args...)() {
>    import std.format;
>    // use types, as otherwise iterating over args may not 
> compile
>    foreach(i, T; types!args) {
>        static if (is(T == string)) {
>            pragma(msg, format!"Argument %d is a string, which 
> is not supported"
>                    (i+1));
>            return false;
>        }
>    }
>    return true;
>}
>
>void foo(Args...)(auto ref Args args)
>if (noStringArgs!args) {
>    // ...
>}


Now if I call foo() with a string argument, I get this:

>foo(1, "a");
>
>
>Argument 2 is a string, which is not supported
>file(line): Error: template foo cannot deduce function from 
>argument types !()(int, string), candidates are:
>file(line): foo(Args...)(auto ref Args arg) if 
>(noStringArgs!args)

That's a little bit better: if foo() fails to compile, I get a 
hint on which
argument is incorrect. However, as you probably can tell, this 
doesn't scale. If
later I decide to provide an overload for foo() that *does* 
accept string
arguments, I'm going to see that message every time a call to 
foo() is made.

What if we allowed constraint expressions, in addition to a type 
convertible to
bool, return a Tuple!(Bool, Msgs), where Bool is convertible to 
bool, and Msgs
is a string[]?
Then my checker could be implemented like this:

>auto noStringArgs(args...)() {
>    import std.format;
>    import std.typecons;
>    string[] errors;
>    foreach(i, T; types!args) {
>        static if (is(T == string)) {
>            errors ~= format!"Argument %d is a string"(i+1));
>        }
>    }
>    if (errors) return tuple(false, ["This overload does not 
> accept string arguments"] ~ errors);
>    return tuple(true, errors.init);
>}

So it would accumulate all concrete error messages for the 
signature, and prefix them with a general descriptive message.
When resolving overloads, the compiler could collect strings from 
such tuples,
and if the resolution (or deduction, in case of single overload) 
fails,
print them as error messages:

>foo(1, "a", 3, "c");
>
>
>file(line): Error: template foo cannot deduce function from 
>argument types !()(int, string), candidates are:
>file(line): foo(Args...)(auto ref Args arg) if 
>(noStringArgs!args):
>file(line):    This overload does not accept string arguments
>file(line):    Argument 2 is a string, which is not supported
>file(line):    Argument 4 is a string, which is not supported

And in case of overloads:

>auto noNumericArgs(args...)() {
>    import std.format;
>    import std.typecons;
>    import std.traits : isNumeric;
>    string[] errors;
>    foreach(i, T; types!args) {
>        static if (isNumeric!T) {
>            errors ~= format!"Argument %d (%s) is a string"(i+1, 
> T.stringof));
>        }
>    }
>    if (errors) return tuple(false, ["This overload does not 
> accept numeric arguments"] ~ errors);
>    return tuple(true, errors.init);
>}
>
>void foo(Args...)(auto ref Args args)
>if (noStringArgs!args) { /* ... */ }
>
>void foo(Args...)(auto ref Args args)
>if (!noStringArgs!args && noNumericArgs!args) { /* ... */ }
>
>foo(1, 2);     // ok, no error, first overload
>foo("a", "b"); // ok, no error, second overload
>foo(1, "b", "c");   // error
>
>
>file(line): Error: template foo cannot deduce function from 
>argument types !()(int, string), candidates are:
>file(line): foo(Args...)(auto ref Args arg) if 
>(noStringArgs!args):
>file(line):    This overload does not accept string arguments
>file(line):    Argument 2 is a string
>file(line):    Argument 3 is a string
>file(line): foo(Args...)(auto ref Args arg) if 
>(!noStringArgs!args && noNumericArgs!args):
>file(line):    This overload does not accept numeric arguments
>file(line):    Argument 1 (int) is numeric

This would clearly show exactly for what reason each overload 
failed. You can
imagine for complex template functions (i.e. likes of 
std.concurrency.spawn, std.getopt,
etc) this could help convey the error much more concisely than 
just saying
"hey, I failed, here are the candidates, go figure it out...".

A crude implementation of this is possible as a library:

https://dpaste.dzfl.pl/0ba0118c3cd9

but without language support, it'll just riddle the compiler 
output with
messages on every call, regardless of the success of overload 
resolution,
so the only use for that would be in case of no overloads. And 
the messages
are ordered before compiler errors, which is less than helpful.

Another idea, instead of using tuples, introduce a stack of 
messages for each
overload, and allow a special pragma during constraint evaluation:

>bool noStringArgs(args...)() {
>    import std.format;
>    import std.typecons;
>    foreach(i, T; types!args) {
>        static if (is(T == string)) {
>            pragma(overloadError, format!"Argument %d is a 
> string"(i+1)));
>            // may return early or continue to collect all errors
>            // return false;
>        }
>    }
>    return true;
>}

pragma(overloadError, string) will "push" an error onto message 
stack.
After evaluating noStringArgs!args, the compiler would check the 
stack, and if
it's not empty, discard the result (consider it false) and use 
the strings from that stack
as error messages.

Trying to call noStringArgs() outside of constraint evaluation 
would result in
compiler error (pragma(overloadError, string) should only be 
available in that
context).

There are other alternatives, e.g. there's a DIP by Kenji Hara:

https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint

The approach I'm proposing is more flexible though, as it would 
allow to
evaluate all arguments as a unit and infer more information (e.g. 
__traits(isRef, args[i]).
Constraint on every argument won't allow the latter, and would 
potentially require writing more explicit overloads.

What do you guys think? Any critique is welcome, as well as 
pointers to alternatives, existing discussions on the topic, etc.