Bugs in template constraints
Andrej Mitrovic
andrej.mitrovich at gmail.com
Tue Aug 3 14:07:21 PDT 2010
On Tue, Aug 3, 2010 at 10:23 PM, Philippe Sigaud
<philippe.sigaud at gmail.com>wrote:
>
>
> On Tue, Aug 3, 2010 at 22:04, Andrej Mitrovic <andrej.mitrovich at gmail.com>wrote:
>
>> Oh and there's a shorter way to write this example, by using isInputRange
>> from std.range, like so:
>>
>> if (isInputRange!R && is(typeof({x = fun(x, range.front);})))
>>
>
> Does this work, without the () after the } ?
>
>
I haven't even noticed those.
In the following, If I add the pair of ()'s I get void as a return type. If
I remove them, I get void delegate():
writeln(typeid(typeof( delegate void () {int x = 1;}()))); // writes void
writeln(typeid(typeof( delegate void () {int x = 1;}))); // writes void
delegate()
So I definitely need to add them. When not added the expression evaluates to
void delegate(), which is a valid type and the constraint then passes.
If I understood everything, this code in the constraint:
is(typeof({x = fun(x, range.front);}() )))
creates an anonymous function, the compiler sees it's trying to access x so
it makes it a delegate, and it infers that the function takes no arguments
and the return type is void. Did I get this right?
This was in TDPL (except the {}'s which are missing).
>
>
> As I said, abstracting away common constraints is a common trick. Have a
> look at std.range, you'll see a bunch of these.
>
>
> Philippe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20100803/3f317e5b/attachment.html>
More information about the Digitalmars-d
mailing list