Bugs in template constraints
Andrej Mitrovic
andrej.mitrovich at gmail.com
Tue Aug 3 13:01:21 PDT 2010
On Tue, Aug 3, 2010 at 9:34 PM, Philippe Sigaud
<philippe.sigaud at gmail.com>wrote:
>
>
> On Tue, Aug 3, 2010 at 20:59, Andrej Mitrovic <andrej.mitrovich at gmail.com>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20100803/74f19cad/attachment.html>
More information about the Digitalmars-d
mailing list