Range Redesign: Copy Semantics

[Jonathan M Davis]

On Sunday, January 21, 2024 7:30:40 PM MST Paul Backus via Digitalmars-d 
wrote:
> On Monday, 22 January 2024 at 02:10:32 UTC, Jonathan M Davis
>
> wrote:
> > On Sunday, January 21, 2024 7:51:33 AM MST Paul Backus via
> >
> > Digitalmars-d wrote:
> >> With the proposed design, it would be possible to implement
>
> >> next() for forward ranges as a UFCS function:
> [...]
>
> > True, but then you have a function with the same copy semantics
> > problem that we have now, since the forward range wouldn't have
> > reference semantics. It would need to be fully wrapped in
> > another type which gave it reference semantics to do that.
>
> You caught me--I forgot to mark the parameter as 'ref'. Dangers
> of writing code directly into a message without testing it first,
> I suppose. :)

Well, even if the parameter is ref (which it would need to be), the core
problem is that the range-based function then has to deal with passing
around an object that could have value semantics even though basic input
ranges would be required to have reference semantics with the proposed
changes. Obviously, range-based code _can_ work without caring about the
copy semantics of the range type, but the main thrust of the proposed
changes is to try to require specific copy semantics from different
categories of ranges so that we can avoid the bugs that come with different
range types having different copy semantics (as well as making it possible
to write code that takes advantage of the specific copy semantics of a
particular category of range; even simply being able to assign one range to
another in generic code would be a big help to some code).

Ideally, code would be able to rely on the copy and assignment semantics of
ranges - and that means not trying to treat basic input ranges and forward
ranges as the same thing without actually wrapping one in a way that forces
it to be the same thing (be it by turning a forward range into a reference
type with the basic input range API or by wrapping a basic input range in a
struct which caches the data such that it can implement the forward range
API). Simply slapping the functions for the other API on one of the two
types will result in ranges that won't behave properly, which will work with
some functions and fail miserably with others.

- Jonathan M Davis