48 hour game jam

[Peter Alexander]

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.