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