More fun with autodecoding

Neia Neutuladh neia at ikeran.org
Sat Sep 15 19:04:17 UTC 2018


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)).

> 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.


More information about the Digitalmars-d mailing list