Andrei Alexandrescu <[email protected]> wrote:
>
> Would it mess your plans if we hold off (at least for now) with getNext?
No. :-) It should be easy to make them to use front etc.
> I feel the consensus is really weak and I'm not sure getNext is a big
> improvement. If we do commit to it, that would probably mean changing
> the core language as well, (foreach) std.algorithm etc.
Agreed. I'll replace getNext with empty/front/popFront.
Actually, I thought I would eventually use the current range primitives
anyway. getNext was not very comfortable to use. (It fairly simplified
streaming range implementation though!)
Here's my feeling about getNext:
- It can't represent infinite ranges.
- Type inference like the following does not work:
auto e = r.front;
- The result is strange: E* getNext(ref E store).
Using pointer is ok for me, but it's strange that returned address may
be either &store or &some_internal_item. store is a sheer temporary
and can't be used intuitively like this:
if (r.getNext(store))
writeln(store); // The front item might not be assigned to store!
Shin
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
