Range Redesign: Copy Semantics

[Jonathan M Davis]

On Sunday, January 21, 2024 10:15:58 AM MST Walter Bright via Digitalmars-d 
wrote:
> Thanks for bringing this up. Improving range semantics is something we
> should not pass up the opportunity for with Phobos3. (I consider Phobos1
> the D1 version, Phobos2 the one we have currently.)
>
> 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.

I will have to study that more to see what's needed there. If it's the kind
of thing that requires higer level locking than simply locking within the
implementations of existing range-based functions (e.g. if it had to be
locked across multiple calls), then that likely either merits a non-standard
extension that the user has to worry about that's specific to stdio stuff,
or we'll need to come up with some sort of higher level addition to handle
it. I very much doubt that it's the sort of thing that's going to make much
sense to worry about within most range-based functions though. I will add it
to the list of things to look into though.

There are several other minor changes that I think are going to be needed to
the range API (e.g. requiring that random-access ranges implement opDollar
rather than letting it be optional, since it's useless if it's optional like
it is now), but the core point of this thread was to try to sort out the
issue of the copy and assignment semantics for ranges, and the best solution
for that seems to be to get rid of save (which would allow all forward
ranges to behave like dynamic arrays as far as their copy, assignment, and
iteration semantics go) and to make basic input ranges distinct from forward
ranges, since they fundamentally can't have the same semantics.

The issue of tail-const is going to be another big one, though that could
result in us having to switch to a head/tail model for forward ranges
instead of front/popFront - either that, or we're going to need a language
improvement of some kind to sort it out, since we need to be able to
generically get a tail-const copy of a forward range, whereas we currently
don't have a way to convert const(Range!Element) to Range!(const Element).
We can't even assume that const(Range!Element) is the same as
const(Range!(const Element)). So, there are definitely further issues that
will need to be hashed out beyond the copy semantics. I just decided to
start with that.

- Jonathan M Davis