48 hour game jam

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Oct 15 12:54:43 PDT 2012


On Mon, Oct 15, 2012 at 09:18:33PM +0200, Peter Alexander wrote:
[...]
> I'm going to start a bit of a rant now.
> 
> D templates are certainly powerful, and are inarguably an
> improvement over C++ templates, but they are still based on C++
> templates, and inherit a lot of their fundamental problems.
> 
> The main problem is the whole duck typing thing. Duck typing is the
> cause of all the horrible error messages in C++ templates, and D
> carried it over.
> 
> Consider this:
> 
> auto s = chain("a,b,c,", "d,e,f").splitter(",");
> 
> Seems like a reasonable thing to do, but you get an error:
> 
> 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.


> What am I supposed to make of that?
> 
> D attempts to mitigate this by adding template constraints, but this
> just makes the error messages shorter, not more useful. Here's
> another example, this time trying to instantiate a constrained
> template:
> 
> bool b = filter!(not!isPunctuation)("Hello,
> world!").endsWith("world");
> 
> Again, seems reasonable. I want to remove all the punctuation from a
> string and then test if it ends with the word "world". Again, I get
> an error:
> 
> Error: template std.algorithm.endsWith does not match any function
> template declaration
> std/algorithm.d(4375): Error: template std.algorithm.endsWith cannot
> deduce template function from argument types
> !()(FilterResult!(not,string),string)

I agree that this error message is stupid. I've found myself having to
insert pragma(msg,...)'s into my code just to see what exactly were the
types that failed to match the template constraints.

But to me, this is more of an implementational issue with the current
dmd than a weakness of the language itself. If the templates were
well-designed in the first place, the signature constraints ought to
look something like:

	auto endsWith(R,S)(R range, S endswiththis)
		if (isInputRange!R && isForwardRange!S && ...)

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


> This error message is no more useful than saying "you can't do
> that". Why doesn't any function match? Why can't it deduce the
> template parameters?
> 
> I don't believe there's any easy way to solve these problems with
> the current template design. You really need something like concepts
> or typeclasses to get quality errors. These aren't things that are
> easily tacked on.
[...]

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.


T

-- 
Arise, you prisoners of Windows / Arise, you slaves of Redmond, Wash, / The day and hour soon are coming / When all the IT folks say "Gosh!" / It isn't from a clever lawsuit / That Windowsland will finally fall, / But thousands writing open source code / Like mice who nibble through a wall. -- The Linux-nationale by Greg Baker


More information about the Digitalmars-d mailing list