Range Redesign: Copy Semantics

[Paul Backus]

On Sunday, 21 January 2024 at 17:15:58 UTC, Walter Bright wrote:
> Another thing that should be visited is the ability to 
> lock/unlock a range. For example, a range that represents 
> stdout needs to be lockable.

Surely this would be better handled outside the range API.

E.g., you call a library function that locks stdout and returns a 
range, and then when you're done with the range, it unlocks 
stdout again in its destructor. But the functions you pass the 
range to (map, filter, whatever) don't need to know anything 
about locking.

This *would* be a good use-case for a non-copyable range, since 
you only want to unlock once (and reference counting would add 
significant overhead). So even if we don't *require* ranges to be 
non-copyable, we probably want to *allow* then to be.