Range Redesign: Copy Semantics

[Jonathan M Davis]

On Sunday, January 21, 2024 12:24:20 PM MST Steven Schveighoffer via 
Digitalmars-d 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.

Yeah, I was orignally hoping that this sort of thing could just be solved
with editions, but regardless of what we do with editions and Phobos, third
party code won't necessarily be updated to match, and it won't even
necessarily be obvious whether it has been. To an extent, that doesn't
really matter, and we could theoretically punt on the issue based on the
idea that any basic input ranges written to follow the Phobos v2 API would
just behave incorrectly with functions written to follow the Phobos v3 API
for forward ranges, so testing would catch it, but that's obviously not
ideal. It _could_ be caught if we required all basic input ranges to be
either class references or pointers to structs, while requiring that all
forward ranges be structs or dynamic arrays (and we will have to do the
latter), but that would arguably restrict the implementation of basic input
ranges too much (e.g. reference counting wouldn't be possible).

For better or worse, it's definitely an argument for switching to a more
functional-style API like Paul mentioned and like has occasionally been
discussed in the past (usually as a potentially solution to the tail-const
and tail-immutable issue). That would actually allow us to solve other
problems rather than simply being a minor API change just to make it so that
we could detect the difference, though I'm not sure what all of the other
consequences of such a change would be (particularly with regards to
performance).

- Jonathan M Davis