Requirements for Slicing Ranges

[Sebastiaan Koppe]

On Monday, 2 September 2024 at 02:47:16 UTC, Jonathan M Davis 
wrote:
> Does anyone know of a situation where that would not be the 
> case? I would love to just ditch the test for slicing in the 
> updated range API and tie the ability to random-access ranges, 
> since it would be simplify things. If I had to guess without 
> digging through all of the history, I suspect that 
> random-access ranges were added before slicing was and that 
> that's why they weren't tied together, but in practice, they 
> always seem to be, and I can't think of a reason at the moment 
> why they can't be.
>
> Can anyone see something that I'm missing here?
>
> - Jonathan M Davis

I briefly wondered how it would work if the range is 
non-copyable, since taking a slice is effectively taking a copy 
of the underlying data the range captures (and its lifetime). But 
I remember you saying in another thread that forward ranges have 
to be copyable, correct?

So I guess the question for me boils down to whether there exists 
a need for a non-copyable range that provides random access and 
doesn't allow copies. (Although I guess with ref and dip1000 you 
could make that work, but lets not go there :smile).