Generators in D

[Piotr Szturmaj]

Andrei Alexandrescu wrote:
> On 05/10/2011 07:06 PM, Piotr Szturmaj wrote:
>> I forgot to ask. Any comments or suggestions?
>
> This is solid work, and very interesting. I wonder how we can integrate
> it best with Phobos (e.g. put in its own module vs. integrating into
> std.range).

This code is very short so integrating it with std.range might be a 
better choice.

> I suggest you write an article about this artifact. Don't forget that
> the deadline for the iPad contest is June 1st.

I'll see what I can do :-)

> A few nits follow.
>
> * "Fiber fiber = Fiber.getThis();" -> "auto fiber = Fiber.getThis();"
>
> * "_generator" -> "Generator" (private names are not exempt from the
> recommended conventions)

Fixed.

> * "staticLength!T" -> what's wrong with T.length?

I have seen this many times in the library, example from std.traits:

template ReturnType(/+@@@BUG4217@@@+/func...)
     if (/+@@@BUG4333@@@+/staticLength!(func) == 1)

And I realized that as a good idea, because bug 4333 is not closed yet.

> * import inside a template is unusual, why did you need it that way?

I needed TypeTuple only inside this template, so I though I will hide it 
there :-) But after rethinking it, I think it's better to put that in 
module beginning with other imports.

> * "pure nothrow ValueType front()" -> that probably should be a
> @property (sigh)

Fixed in empty() as well.

> * can you implement save() to make this a forward range (e.g. by
> creating a new fiber that has its own state)?

It is not that simple I guess. Fiber class doesn't give any opportunity 
to save current stack and I think it might be wrong to do this, because 
of GC issues. But I don't certainly know.

I think that author of the Fiber class could answer this better than me.
If Fiber will expose some additional API, then I would certainly 
implement save().

> Thanks,
>
> Andrei

Thanks for the feedback!