Range Redesign: Copy Semantics

[Jonathan M Davis]

On Wednesday, January 24, 2024 12:23:45 PM MST Alexandru Ermicioi via 
Digitalmars-d wrote:
> On Wednesday, 24 January 2024 at 18:20:38 UTC, Paul Backus wrote:
> > The entire range API is based on convention to begin with. Of
> > course there's no enforcement mechanism!
>
> Isn't `isInputRange`, `isForwardRange`, and the rest, kind of
> enforcement machanism?

Traits like that can test (and thus be used to enforce) _some_ of the
semantics, but there are plenty of things that can't be tested statically
(like what popFront actually does). They are able to test that certain code
will compile with the range API (or that certain code won't compile) using
the type that they're instantiated with, and they can test certain explicit
stuff about the type (e.g. enforcing that it's a struct if we want to do
that), but they can't actually test what the functions do.

So, while we can enforce that a forward range is copyable, we can't enforce
what its copy semantics are beyond disallowing stuff like classes or
pointers to structs, since those are clearly reference types. But the struct
itself could have a variety of copy semantics depending on its
implementation, and there's no way to determine that statically. Ultimately,
for a range to have the correct copy semantics, we have to rely on the
programmer to implement them correctly, just like we have to rely on them
implementing what front, popFront, and empty do correctly.

- Jonathan M Davis