Range Redesign: Copy Semantics

[Paul Backus]

On Sunday, 21 January 2024 at 19:24:20 UTC, Steven Schveighoffer 
wrote:
> While I agree with most of what you wrote, there is one very 
> big problem with this. Namely, current input ranges are 
> suddenly considered to be forward ranges. Changing the 
> semantics of what it means to only define `front`, `popFront`, 
> and `empty` changes the semantics of existing code.
>
> And this is not something you can solve with some kind of 
> versioning. The only way I can think of is to alter the name of 
> one or more primitives to prevent accidental usage.

One possibility is to change the forward range interface to 
something like

     bool empty();
     Element head();
     typeof(this) tail();

In addition to distinguishing new-style forward ranges from 
old-style ones, this interface would also allow forward ranges to 
be `const` (although iterating a `const` forward range would only 
be possible with recursion).

`popFront` could then be implemented as a UFCS function:

     void popFront(R)(ref R r)
         if (std.v2.range.isForwardRange!R && isAssignable!R)
     {
         r = r.tail;
     }