Thread overview
[phobos] phobos commit, revision 1767
Jul 18, 2010
dsource.org
Jul 19, 2010
Shin Fujishiro
July 18, 2010
phobos commit, revision 1767


user: rsinfu

msg:
[devel] std.range: Added ad-hoc support for the getNext.

- Made isInputRange!R to look for getNext.
- Made ElementType!R to deal with getNext.

http://www.dsource.org/projects/phobos/changeset/1767

July 19, 2010
Hi Shin,


Great work on the Windows console encoding!

Would it mess your plans if we hold off (at least for now) with getNext? 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.


Andrei

On 07/18/2010 05:53 PM, dsource.org wrote:
> phobos commit, revision 1767
>
>
> user: rsinfu
>
> msg:
> [devel] std.range: Added ad-hoc support for the getNext.
>
> - Made isInputRange!R to look for getNext.
> - Made ElementType!R to deal with getNext.
>
> http://www.dsource.org/projects/phobos/changeset/1767
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
July 20, 2010
Andrei Alexandrescu <andrei at erdani.com> 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