Range Redesign: Copy Semantics

[Atila Neves]

On Monday, 22 January 2024 at 17:18:56 UTC, Paul Backus wrote:
> On Monday, 22 January 2024 at 15:41:35 UTC, Atila Neves wrote:
>> I think that `.save` was a historical mistake, and that ranges 
>> that can be copied are forward ranges. Something like a range 
>> reading from stdin or a socket would/should disable the 
>> copy/postblit constructors.
>
> This was my initial thought too, but it turns out it's not 
> quite that simple.
>
> If we *require* basic input ranges to be non-copyable,

I don't think we should that because algorithms that don't care 
if a range is copiable (i.e. forward) or not should be usable 
with any input range.

> then types which are inherently copyable (in particular, `T[]`) 
> will be exclude from being basic input ranges. In order to use 
> a `T[]` with an algorithm that expects a basic input range, you 
> would have to wrap it in a `struct` that has copying disabled.

That would indeed be a mistake, but the forward range 
concept/template constraint is a... err... "subtype" of input 
ranges, so it *should* work. My idea here is changing the concept 
of forward ranges from ones that can have `.save` called on them 
to ones that can be copied. If that works, of course.

The case against the idea is that right now, range authors have 
to opt-in to "forwardness", whereas copies have to be disabled to 
opt-out.

> It's also a big problem for composability. If half the 
> algorithms require your range to be copyable, and the other 
> half require it to be non-copyable, you have to keep track of 
> [what color each algorithm is][1] whenever you write a range 
> pipeline, or write a new algorithm that calls an existing one 
> internally.

This is the case already (sort of) with functions that expected 
isForwardRange!R vs isInputRange!R, the difference being a 
relationship of subtyping that makes it that all forward ranges 
are also input ranges.