Bugs in template constraints

[Philippe Sigaud]

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())))
{...}

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20100803/0ca9b6db/attachment.html>