On Monday, 15 October 2012 at 19:52:44 UTC, H. S. Teoh wrote:
On Mon, Oct 15, 2012 at 09:18:33PM +0200, Peter Alexander wrote:
std/algorithm.d(2020): Error: undefined identifier 'length'
... similar errors from inside std.algorithm ...
This looks like a bug. There should be signature constraints to
test for
the existence of .length before attempting to use it.
It is, I've already created a pull request for it.
Problem is, there's many more where that came from. And even if
you fix everything in the standard library, you then have to
worry about all the 3rd party libraries out there with inadequate
constraints.
Now, if the compiler would just say something along the lines
of:
template std.algorithm.endsWith does not match arguments:
FilterResult!(blahblah) fails constraints: isForwardRange,
isInputRange, (or whatever)
That would be much better. The constraint names themselves will
already
have told you what was wrong (assuming their names were
well-chosen in
the first place -- which I submit is a reasonable expectation,
given
that Phobos is the *standard* library).
It's not that simple.
First, there are often multiple overloads, so you not only have
to show why one overload failed, you have to show why all of them
failed.
Second, not all constraints are simply (isX && isY && isZ). They
often contain things like complex is-expression and allSatisfy
etc.
Third, telling me that FilterResult failed a constraint isn't
particularly enlightening either. Why isn't FilterResult a
forward range (or whatever)? I didn't write it. I have to now go
and look at the source of both isForwardRange and FilterResult to
figure out where the mismatch is (compare this to, for example,
just checking that a class implements an interface).
To me, the current template design already models
concepts/typeclasses.
Things like isInputRange, isForwardRange, etc., are
self-documenting,
and they describe concepts and type classes -- if the compiler
would
only _use_ them in the error message instead of the current
encrypted
Klingon. I chalk it up to a dmd enhancement request.
This is a "sufficiently smart compiler" argument. Template
constraints have been around for a long time, and the situation
hasn't improved. To me, that's a hint that providing good error
messages is a difficult task (like implementing export in C++). A
simpler language design would enable a quicker and more robust
implementation.
