Range Redesign: Copy Semantics

[Sebastiaan Koppe]

On Sunday, 21 January 2024 at 05:00:31 UTC, Jonathan M Davis 
wrote:
> I've been thinking about this for a while now, but with the 
> next version of Phobos which is in the early planning stages, 
> we really should do some redesigning of ranges.

Thanks for the write up.

Another issue I have encountered is around priming. Sometimes it 
happens in `empty`, sometimes in a private helper function and 
sometimes even in the constructor.

If priming happens in `empty`, then it can't be `const`. Which is 
strange because you would expect `empty` not to mutate.

I have been thinking about having an explicit build and iteration 
phase, where priming happens when you switch from build to 
iteration.

The benefit is that implementers have a clear place where to 
prime the range.

> What I would propose for that would be a single function
>
>    auto next();
>
> where next returns a nullable type where the value returned is 
> the next element in the range, with a null value being returned 
> if the range is empty.

What about:

```
     bool next(Callable)(Callable c) {
         if (empty)
             return false;
         c(front());
         popFront();
         return true;
     }
```

It has the benefit of not needing to unbox a Nullable/Pointer.