opNext: Simplified ranges (page 2)

On Sunday, 6 November 2022 at 07:55:13 UTC, Tomer@Weka wrote: > On Sunday, 6 November 2022 at 01:48:04 UTC, Walter Bright wrote: >> We didn't use the "next" protocol for ranges because one cannot test for existence of the next element without consuming it. > > But that's exactly the issue - I have to produce the element in the range's ctor, which essentially requires a "non-popping popNext" to determine if it's empty and assign the front > > -tomer Doesn't one the solutions from Steven or Dukec work?

November 06, 2022

Re: opNext: Simplified ranges

Posted by Steven Schveighoffer
in reply to Tomer@Weka

Permalink

Steven Schveighoffer

Posted in reply to Tomer@Weka

Permalink

On 11/6/22 2:55 AM, Tomer@Weka wrote:

On Sunday, 6 November 2022 at 01:48:04 UTC, Walter Bright wrote:

We didn't use the "next" protocol for ranges because one cannot test for existence of the next element without consuming it.

But that's exactly the issue - I have to produce the element in the range's ctor, which essentially requires a "non-popping popNext" to determine if it's empty and assign the front

The issue there is that you are making a copy, and the copy has already consumed the front element. It would be no different with your API as well -- if you break from your range type, the element is gone.

What we need is non-copyable input ranges. I have advocated for this for a while. In essence, a forward range should be copyable, an input range should not be, and we should remove save. Then when you foreach it, you can't make a copy, so it doesn't let you discard the element you are looking at.

The other option is -- don't use foreach. Use a while loop like you wrote.

-Steve

On Sunday, 6 November 2022 at 22:32:00 UTC, Sebastiaan Koppe wrote:

On Sunday, 6 November 2022 at 21:08:10 UTC, Per Nordlöw wrote:

It all boils down to fitting the design to the most common use case. So is the most common case to be able to peek or not? I really don't know right. Does anybody have any insights into this?

I actually think the most lowest range should be one with destructive read semantics; non-peekable, non-copyable. You can build everything on top of that.

I also think ranges should be redesigned to have a 2 stage api. One to build the pipeline, one to iterate.

You have talked about redesigning ranges multiple times before as well, plus have expierience using them non-trivially for quite some time.

Could you please create a post/document that contains all your ideas/thoughts about what a redesigned range would look like? The maybe someone could actually work towards implementing it. If not directly within phobos, then atleast they could create a package and we could test the new ranges' efficacy for real world usage

On 11/6/22 22:06, Per Nordlöw wrote: > On Sunday, 6 November 2022 at 01:48:04 UTC, Walter Bright wrote: >> We didn't use the "next" protocol for ranges because one cannot test for existence of the next element without consuming it. > > That's not a blocker if we can afford implementing a second function for the "peek" case. This is the path Rust took via its `Peekable` trait and `peek()` member as described at > > https://doc.rust-lang.org/stable/std/iter/struct.Peekable.html > > . This does more than just check for existence; the range will have to cache the next element, which is the issue OP is trying to fix I think.

Forums