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