Range Redesign: Copy Semantics

[Paul Backus]

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, 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.

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.

[1]: 
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/