On Tue, Aug 3, 2010 at 9:34 PM, Philippe Sigaud <[email protected]>wrote:
> > > On Tue, Aug 3, 2010 at 20:59, Andrej Mitrovic > <[email protected]>wrote: > >> There seem to be some bugs with template constraints. Here's a reduce >> example (from TDPL) which will not compile: >> >> >> V reduce(alias fun, V, R)(V x, R range) >> if (is(typeof(x = fun(x, range.front))) >> && is(typeof(range.empty) == bool) >> && is(typeof(range.popFront()))) >> > > >> I'm filing a bug unless something else is to blame here. >> > > I think that's because you cannot directly take the type of a statement. > The assignment in the first typeof() is to blame. To make a statement into > an expression, transform it into an anonymous void delegate(): put it in > braces (with a semicolon at the end) and call it like a function, like this: > > V reduce(alias fun, V, R)(V x, R range) > if (is({ typeof(x = fun(x, range.front);}())) > && is(typeof(range.empty) == bool) > && is(typeof(range.popFront()))) > {...} > > The { comes after "typeof(" as in your second example, and then it compiles. > Or, more readable, wrap all the code you want to test into curly brackets > and evaluates its global return type: > > > V reduce(alias fun, V, R)(V x, R range) > if (is(typeof({ // I want to be able to do > that with an R and a V: > x = fun(x, range.front); > if (range.empty) {}; > range.popFront(); > }()))) > > {...} > > It's a D idiom you'll see in many places in the standard library. I > personally find it a _bit_ heavy on parenthesis, even though I like Lisp. > > > Philippe > Yeah, those paranthesis are getting a bit scary now. :) I guess this one goes to the TDPL errata. Thanks for your help Philippe.
