More fun with autodecoding

[Steven Schveighoffer]

On 9/15/18 12:04 PM, Neia Neutuladh wrote:
> On Saturday, 15 September 2018 at 15:31:00 UTC, Steven Schveighoffer wrote:
>> The problem I had was that it wasn't clear to me which constraint was 
>> failing. My bias brought me to "it must be autodecoding again!". But 
>> objectively, I should have examined all the constraints to see what 
>> was wrong. All C++ concepts seem to do (haven't used them) is help 
>> identify easier which requirements are failing.
> 
> They also make it so your automated documentation can post a link to 
> something that describes the type in more cases. std.algorithm would 
> still be relatively horked, but a lot of functions could be declared as 
> yielding, for instance, ForwardRange!(ElementType!(TRange)).

True, we currently rely on convention there. But this really is simply 
documentation at a different (admittedly more verified) level.

> 
>> We can fix all these problems by simply identifying the constraint 
>> clauses that fail. By color coding the error message identifying which 
>> ones are true and which are false, we can pinpoint the error without 
>> changing the language.
> 
> I wish. I had a look at std.algorithm.searching.canFind as the first 
> thing I thought to check. Its constraints are of the form:
> 
>      bool canFind(Range)(Range haystack)
>      if (is(typeof(find!pred(haystack))))
> 
> The compiler can helpfully point out that the specific constraint that 
> failed was is(...), which does absolutely no good in trying to track 
> down the problem.

is(typeof(...)) constraints might be useless here, but we have started 
to move away from such things in general (see for instance isInputRange 
and friends).

But there could actually be a solution -- just recursively play out the 
items at compile time (probably with the verbose switch) to see what 
underlying cause there is.

Other than that, you can then write find(myrange) and see what comes up.

In my case even, the problem was hasSlicing, which itself is a 
complicated template, and wouldn't have helped me diagnose the real 
problem. A recursive display of what things failed would help, but even 
if I could trigger a way to diagnose hasSlicing, instead of copying all 
the constraints locally, it's still a much better situation.

I'm really thinking of exploring how this could play out, just toying 
with the compiler to do this would give me experience in how the thing 
works.

-Steve