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.

Nobody read that or is it just *that* bad? :)

On 5/13/17 10:41 AM, Stanislav Blinov wrote:
> 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)

I think the compiler should be able to figure this out, and report it. The if constraint is a boolean expression, and so it can be divided into the portions that pass or fail.

What I'd love to see is the constraint colorized to show green segments that evaluate to true, and red segments that evaluate to false. And then recursively show each piece when asked.

I think any time spent making a user-level solution will not scale. The compiler knows the information, can ascertain why it fails, and print a much nicer error message. Plus it makes compile-time much longer to get information that is already available.

Imagine also a constraint like isInputRange!R. This basically attempts to compile a dummy lambda. How would one handle this in user-code?

I think there are several forum threads about diagnosing constraint issues, haven't got the time right now to look for them.

-Steve

On Monday, 15 May 2017 at 15:30:38 UTC, Steven Schveighoffer wrote:

>>> 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)
>
> I think the compiler should be able to figure this out, and report it. The if constraint is a boolean expression, and so it can be divided into the portions that pass or fail.

How? The constraint, any constraint, is de-facto user code. Even in the simple example I've provided, I would not expect the compiler to figure out what are *my* expectations on the types. I provide code for doing that, the language gives me means to that effect. What it doesn't give me though is a way to cleanly report an error.
Even if the compiler was to divide the constraint into blocks and reason about them separately, it's still limited to error reporting we have now: it will report "is(T == string) was expected to be false, but it's true". Is that a good error message?

> What I'd love to see is the constraint colorized to show green segments that evaluate to true, and red segments that evaluate to false. And then recursively show each piece when asked.
>
> I think any time spent making a user-level solution will not scale. The compiler knows the information, can ascertain why it fails, and print a much nicer error message. Plus it makes compile-time much longer to get information that is already available.

I don't see how that is possible. The constraints' complexity is arbitrary, it's semantics are arbitrary. The compiler does a full semantic pass, we end up with the error messages as if it was normal program code. But the thing is, we need different error messages, because it isn't "normal" program code.
In fact, what truly doesn't scale is the binary "is/isn't" solution we have now. Again, even if the compiler would display at which line/column `false` was inferred, it's not good enough, as it simply leaves the user to figure out what went wrong, without any clear hint.

> Imagine also a constraint like isInputRange!R. This basically attempts to compile a dummy lambda. How would one handle this in user-code?

Umm... Exactly as it is implemented currently? With one important distinction that I would be able to report *exactly why* the type in question does not satisfy the constraint. Not an obscure

"Error: no property 'empty' for type (typename)"
"Error: expression 'foo.front()' is void and has no value"

but a descriptive

" Argument <number> does not satisfy the constraint isInputRange:"
"(typename) is expected to be an input range, but it doesn't implement the required interface:"
"   property 'empty' is not defined."
"   property 'front' is defined, but returns void."

User code can collect all the information and present it in a readable way. Compiler will never be able to. The best the compiler would do is report "T does not satisfy isInputRange". And in my opinion, that is what it should do. Adding complexity to the compiler to figure out all imaginable variations doesn't seem like a very good idea. User code is able to make all assessments it needs, it just doesn't have the ability to elaborate.

Another example:

is(typeof(x) == string) && x.startsWith("_")

The best we can expect from the compiler is print that out and say it evaluated to false.
User code, on the other hand, can generate a string "x must be a string that starts with an underscore". Which one is better?

On Monday, 15 May 2017 at 15:30:38 UTC, Steven Schveighoffer wrote:

> Imagine also a constraint like isInputRange!R. This basically attempts to compile a dummy lambda. How would one handle this in user-code?

Let's look at something more practical than my initial example, even if less involved than isInputRange. In a discussion not long ago it was brought up that a destructive variant of move() violates const, and this was the response:

http://forum.dlang.org/post/odlv7q$16dr$1@digitalmars.com

So let me try implementing the "should fail in all cases" bit.

>enum bool isMovable(T) = {
>    import std.traits;
>    static if (!isMutable!T)
>        return false;
>    static if (is(T == struct) &&
>            (hasElaborateDestructor!T || hasElaborateCopyConstructor!T)) {
>        foreach (m; T.init.tupleof) {
>            static if (!isMovable!(typeof(m)) && (m == m.init)) {
>                return false;
>            }
>        }
>        return true;
>    } else
>        return true;
>}();

Not exactly a one-liner. There are several checks to be made:

- if the type itself is const/immutable, it can't be moved (can't write to const).
- if it's a struct, each member has to be checked. We can't do this check with isAssignable, since assignment might be redefined.
- if a member is const/immutable, we should check it's init value: if it differs from default, no constructor can change it, so it's "safe" to move destructively (provided a more involved implementation of move() than it is at the moment).
- maybe one or two cases that I forgot

Note that the compiler doesn't deal in the logic listed above. It deals in statements and expressions written inside that lambda. But as I'm writing it, I already possess all the information required to convey the description of failure in a human-readable manner. What I don't have is the means to present that information.

And now:

>T move(T)(ref T src) if (isMovable!T) { /*...*/ }
>void move(T)(ref T src, ref T dst) if (isMovable!T) { /*...*/ }
>
>struct S {
>    const int value; // no default initialization, we initialize in ctor
>    this(int v) { value = v; }
>    ~this() {}  // "elaborate" dtor, we should only move this type destructively
>}
>
>S a;
>auto b = move(a);

All I realistically would get from the compiler is that it can't resolve the overload, and, perhaps with some improvement in the compiler, the line in the lambda that returned false, no more. Something along the lines of:

>            static if (!isMovable!(typeof(m)) && (m == m.init)) {
>                return false;
>                       ^
>                       |

Even though this looks a tiny bit better than what we have now, it actually isn't. A user will have to look at the code of that lambda and parse it mentally in order to understand what went wrong. Whereas I could simply include actual descriptive text like

"S cannot be moved because it has a destructor and uninitialized const members."

On 5/15/17 1:16 PM, Stanislav Blinov wrote:
> On Monday, 15 May 2017 at 15:30:38 UTC, Steven Schveighoffer wrote:
>
>>>> 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)
>>
>> I think the compiler should be able to figure this out, and report it.
>> The if constraint is a boolean expression, and so it can be divided
>> into the portions that pass or fail.
>
> How? The constraint, any constraint, is de-facto user code.

Code evaluated at compile time. It actually has to evaluate each of the pieces, and knows why the whole if statement fails exactly.

The constraint:

void foo(T)(T t) if (cond1!T && cond2!T && cond3!T), the compiler knows both what each of those terms evaluate to, and therefore which ones are causing the thing not to be enabled.

> Even in the
> simple example I've provided, I would not expect the compiler to figure
> out what are *my* expectations on the types.

I think you misunderstand, your example would still not compile, and instead of "here are all the ones I tried", it's "here are all the ones I tried, and in each case, I've highlighted why it didn't work".

Many times, you can figure out by looking at the constraints why it didn't work. However, I've encountered many cases where it's saying it doesn't pass isSomeDoodad!T when I thought T is a doodad. Then I need to figure out why it's not working.

Even your library code cannot be all-knowing about what the calling user is trying to do. It may be confusing to him as well. But just "here's a giant if statement, I as the compiler have figured out why it's not true, see if you can too!" is crap.

> Even if the compiler was to divide the constraint into blocks and reason
> about them separately,

It is.

> it's still limited to error reporting we have
> now: it will report "is(T == string) was expected to be false, but it's
> true". Is that a good error message?

Yes. It's a perfect error message actually. What is confusing about it?

>
>> What I'd love to see is the constraint colorized to show green
>> segments that evaluate to true, and red segments that evaluate to
>> false. And then recursively show each piece when asked.
>>
>> I think any time spent making a user-level solution will not scale.
>> The compiler knows the information, can ascertain why it fails, and
>> print a much nicer error message. Plus it makes compile-time much
>> longer to get information that is already available.
>
> I don't see how that is possible. The constraints' complexity is
> arbitrary, it's semantics are arbitrary. The compiler does a full
> semantic pass, we end up with the error messages as if it was normal
> program code. But the thing is, we need different error messages,
> because it isn't "normal" program code.

It has to know. It has to evaluate the boolean to see if it should compile! The current situation would be like the compiler saying there's an error in your code, but won't tell you the line number. Surely it knows.

>> Imagine also a constraint like isInputRange!R. This basically attempts
>> to compile a dummy lambda. How would one handle this in user-code?
>
> Umm... Exactly as it is implemented currently? With one important
> distinction that I would be able to report *exactly why* the type in
> question does not satisfy the constraint. Not an obscure
>
> "Error: no property 'empty' for type (typename)"
> "Error: expression 'foo.front()' is void and has no value"
>
> but a descriptive
>
> " Argument <number> does not satisfy the constraint isInputRange:"
> "(typename) is expected to be an input range, but it doesn't implement
> the required interface:"
> "   property 'empty' is not defined."
> "   property 'front' is defined, but returns void."

The first would be great. I'm having trouble really seeing a reason to prefer the second over the first, it's just a verbose description of the same thing.

Today we get an error that:

void foo(R)(R r) if(isInputRange!R)

doesn't compile for the obvious (to you) range type R. What it doesn't tell you is anything about why that doesn't work. We don't even get the "no property empty" message.

Let me give you a real example. The isForwardRange test used to look like this:

template isForwardRange(R)
{
     enum isForwardRange = isInputRange!R && is(typeof(
     (inout int = 0)
     {
         R r1 = R.init;
         static assert (is(typeof(r1.save) == R));
     }));
}

Here is the definition of isInputRange:

template isInputRange(R)
{
    enum bool isInputRange = is(typeof(
    (inout int = 0)
    {
        R r = R.init;     // can define a range object
        if (r.empty) {}   // can test for empty
        r.popFront();     // can invoke popFront()
        auto h = r.front; // can get the front of the range
    }));
}

Simple, right? However, this was the situation before I applied a fix:

struct ForwardRange
{
   int front() { return 1; }
   void popFront() {}
   enum empty = false;
   ForwardRange save() { return this; }
}

static assert(isInputRange!R);
static assert(!isForwardRange!R);

You tell me, what is the issue? Having library-writer defined error messages are not going to help there because I didn't do it *exactly* right.

If you aren't sure what the answer is, here is the PR that fixed it: https://github.com/dlang/phobos/pull/3276

> User code can collect all the information and present it in a readable
> way. Compiler will never be able to. The best the compiler would do is
> report "T does not satisfy isInputRange". And in my opinion, that is
> what it should do. Adding complexity to the compiler to figure out all
> imaginable variations doesn't seem like a very good idea. User code is
> able to make all assessments it needs, it just doesn't have the ability
> to elaborate.

No, the compiler just needs to detail its evaluation process that it's already doing.

If the constraint doesn't actually match the pragma message, you get MISLEADING messages, or maybe messages when it actually compiles. Much better to have the compiler tell you actually what it's doing.

>
> Another example:
>
> is(typeof(x) == string) && x.startsWith("_")
>
> The best we can expect from the compiler is print that out and say it
> evaluated to false.

It can say that is(typeof(x) == string) is false, or x.startsWith("_") is false.

> User code, on the other hand, can generate a string "x must be a string
> that starts with an underscore". Which one is better?

My version. Is x not a string, or does x not start with an underscore? Not enough information in your error message. And it doesn't give me more information than the actual constraint code, it's just written out verbosely.

-Steve

On Monday, 15 May 2017 at 19:44:11 UTC, Steven Schveighoffer wrote:
> On 5/15/17 1:16 PM, Stanislav Blinov wrote:
>> On Monday, 15 May 2017 at 15:30:38 UTC, Steven Schveighoffer wrote:
>>
>>>>> 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)
>>>
>>> I think the compiler should be able to figure this out, and report it.
>>> The if constraint is a boolean expression, and so it can be divided
>>> into the portions that pass or fail.
>>
>> How? The constraint, any constraint, is de-facto user code.
>
> Code evaluated at compile time. It actually has to evaluate each of the pieces, and knows why the whole if statement fails exactly.
>
> The constraint:
>
> void foo(T)(T t) if (cond1!T && cond2!T && cond3!T), the compiler knows both what each of those terms evaluate to, and therefore which ones are causing the thing not to be enabled.

Yes, that is what it is: code. Code that follows language rules, not some ADL. No mater how expressive the language is, it is still code. And if, on compile error, the compiler shows me the code from the foreign library that I thought I was using correctly, I'm supposed to now do what the compiler just did and figure out where I made a mistake.

>> Even in the
>> simple example I've provided, I would not expect the compiler to figure
>> out what are *my* expectations on the types.
>
> I think you misunderstand, your example would still not compile, and instead of "here are all the ones I tried", it's "here are all the ones I tried, and in each case, I've highlighted why it didn't work". [...]
> [...] Then I need to figure out why it's not working.

It is exactly for the cases where the logic is more complex than a simple test that my proposal is for. I'm not suggesting to abuse it throughout.

>> now: it will report "is(T == string) was expected to be false, but it's
>> true". Is that a good error message?
>
> Yes. It's a perfect error message actually. What is confusing about it?

There is no context. To get at context, I have to look at the code.

>> I don't see how that is possible. The constraints' complexity is
>> arbitrary, it's semantics are arbitrary. The compiler does a full
>> semantic pass, we end up with the error messages as if it was normal
>> program code. But the thing is, we need different error messages,
>> because it isn't "normal" program code.
>
> It has to know. It has to evaluate the boolean to see if it should compile! The current situation would be like the compiler saying there's an error in your code, but won't tell you the line number. Surely it knows.

It "knows" it evaluated false. It doesn't know how to give user a digestible hint to make that false go away.

> Today we get an error that:
>
> void foo(R)(R r) if(isInputRange!R)
>
> doesn't compile for the obvious (to you) range type R. What it doesn't tell you is anything about why that doesn't work. We don't even get the "no property empty" message.

Exactly my point.

> Let me give you a real example. The isForwardRange test used to look like this:
>
> template isForwardRange(R)

I'm going to need to digest that.


> No, the compiler just needs to detail its evaluation process that it's already doing.

That is not enough. Failure may be X levels deep in some obscure chunk surrounded by static ifs and and a bunch of wonky tests involving attempted lambda compilations (which I'd have to parse and "compile" in my head in order to try to understand what failed).

> If the constraint doesn't actually match the pragma message, you get MISLEADING messages, or maybe messages when it actually compiles. Much better to have the compiler tell you actually what it's doing.

The library author is free to take as many passes over their messages as they deem necessary. They can be as vague or as precise as needed. It is their responsibility.

>> Another example:
>>
>> is(typeof(x) == string) && x.startsWith("_")
>>
>> The best we can expect from the compiler is print that out and say it
>> evaluated to false.
>
> It can say that is(typeof(x) == string) is false, or x.startsWith("_") is false.
>
>> User code, on the other hand, can generate a string "x must be a string
>> that starts with an underscore". Which one is better?
>
> My version. Is x not a string, or does x not start with an underscore? Not enough information in your error message. And it doesn't give me more information than the actual constraint code, it's just written out verbosely.

I've already demonstrated that the message text can be made as precise as is required for a concrete use case, there's no need to nitpick ;) I could as easily report either:

"x is not a string"

or

"string x should start with an underscore".

or

"Argument 10 (int) is not a string. This method is only callable with strings that start with an underscore".

"Value of argument 10 (string) does not start with an underscore. This method is only callable with strings that start with an underscore".

I, as a responsible author, can decide what amount of information must be presented. It could be accompanied by code, I'm not against that. The main point is to explain the error without *requiring* the user to use their head as a compiler.

On 5/15/17 4:24 PM, Stanislav Blinov wrote:
> On Monday, 15 May 2017 at 19:44:11 UTC, Steven Schveighoffer wrote:

>> It has to know. It has to evaluate the boolean to see if it should
>> compile! The current situation would be like the compiler saying
>> there's an error in your code, but won't tell you the line number.
>> Surely it knows.
>
> It "knows" it evaluated false. It doesn't know how to give user a
> digestible hint to make that false go away.

I'm going to snip away pretty much everything else and focus on this.

The compiler absolutely 100% knows, and can demonstrate, exactly why a template constraint failed. We don't have to go any further, or make suggestions about how to fix it.

Just output what exactly is wrong, even if you have to recurse into the depths of some obscure template isXXX, and all it's recursively called templates, I can get the correct determination of where either my type isn't right, or the constraint isn't right.

Essentially, the compiler can write "good enough" messages such that both an IDE and a person can understand it. That's all we need. We don't need to translate is(T == string) into "T should be a string" for people to get the meaning.

All we get today is "it didn't work". We can do better: "it didn't work because ...", and all existing template constraints magically get better error messages.

-Steve

On Monday, 15 May 2017 at 20:55:35 UTC, Steven Schveighoffer wrote:
> On 5/15/17 4:24 PM, Stanislav Blinov wrote:
>> On Monday, 15 May 2017 at 19:44:11 UTC, Steven Schveighoffer wrote:
>
>>> It has to know. It has to evaluate the boolean to see if it should
>>> compile! The current situation would be like the compiler saying
>>> there's an error in your code, but won't tell you the line number.
>>> Surely it knows.
>>
>> It "knows" it evaluated false. It doesn't know how to give user a
>> digestible hint to make that false go away.
>
> I'm going to snip away pretty much everything else and focus on this.
>
> The compiler absolutely 100% knows, and can demonstrate, exactly why a template constraint failed. We don't have to go any further, or make suggestions about how to fix it.

In complex constraints, that is not enough. When we have loops (i.e. over arguments, or over struct members), would it report the iteration/name? Would it know to report it if `false` came several levels deep in the loop body? Would it know that we actually *care* about that information? (*cough* C++ *cough* pages and pages of error text because of a typo...)

When we have nested static ifs, it's important to see, at a glance, which parts of the combination were false. Again, if they're several &&, || in a row, or nested, pointing to a single one wouldn't in any way be informative.

When we have tests using dummy lambdas, are we to expect users to immediately extract the lambda body, parse it, and figure out what's wrong?

> Just output what exactly is wrong, even if you have to recurse into the depths of some obscure template isXXX, and all it's recursively called templates, I can get the correct determination of where either my type isn't right, or the constraint isn't right.

Please look over my isMovable example (I'm not sure if you caught it, I posted it as a follow up to my other reply). Suppose the `false` is pointed at by the compiler:

>    else static if (is(T == struct) &&
>            (hasElaborateDestructor!T || hasElaborateCopyConstructor!T)) {
>        foreach (m; T.init.tupleof) {
>            static if (!isMovable!(typeof(m)) && (m == m.init)) {
>                return false;
>                       ^
>                       |
>            }
>        }
>        return true;
>    } else

That is very, *very* uninformative. I don't know which member it was, I don't know which part of the conditional was false. I don't know which part of the conditional further up was true. Would the compiler know to tell me all that? Would it know to test further, to collect *all* information, so that I don't have to incrementally recompile fixing one thing at a time?

Most importantly, as a user who sees this for the first time, I'd have no idea *why* those checks are there. I'd have no context, no grounds to base my reasoning on, so I'd either have to jump back to docs to see if I missed a corner case, or start spelunking code that I didn't write, which is always so fun... Thing is, the compiler is exactly in that position. It doesn't read the docs, ever :) It's always spelunking code written by someone else. It can't tell what the constraint, as a unit, is *actually* testing for. It doesn't care that we shouldn't destructively move structs with const members. So it wouldn't be able to tell me either. All it will do is report me that that false was returned on that line, and (hopefully), some additional info, like member type and name.

On Saturday, 13 May 2017 at 14:41:50 UTC, Stanislav Blinov wrote:
>>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))

Ya know, even a simple new line before "candidates are:" would improve this error message!

https://issues.dlang.org/show_bug.cgi?id=17400

I know it seems trivial, but attention to detail does make a difference, so I decided to make an issue for it anyway... :-/