Must ranges support `r1 = r2;`?

[Jonathan M Davis]

On Monday, April 16, 2018 15:58:34 Jack Stouffer via Digitalmars-d wrote:
> On Saturday, 24 March 2018 at 21:44:35 UTC, ag0aep6g wrote:
> > Long version: <https://issues.dlang.org/show_bug.cgi?id=18657>
> > ("std.range and std.algorithm can't handle refRange").
> >
> > Short version: With two `std.range.RefRange`s, `r1 = r2;` does
> > not what other Phobos code expects.
> >
> > Question is: Who's at fault? Where do I fix this? Do ranges
> > have to support assignment as expected - even though std.range
> > doesn't mention it? Or should range-handling code never do that
> > - even though it comes naturally and is widespread currently?
>
> Posting this from the PR.
>
> This is a band-aid over the issue of what to do with funky
> operator overloads in ranges. In conjunction with this issue, you
> also have to assume that one could do stuff in the ctor that
> would mess up existing range code in Phobos. What really needs to
> happen is the range spec needs to be updated with a clear list of
> assumptions that Phobos makes in regards to these functions. I'm
> pretty sure that RefRange would have been designed differently if
> the designer realized the results of overloading opAssign like
> that.
>
> In a perfect world, we'd have a pre-constructed test suite that
> people could plug their range (with some data in it) into, where
> all the tests make sure all Phobos assumptions hold true.
>
> In my opinion, it would be best to update the range spec and go
> from there.

Well, the reality of the matter is that if RefRange's opAssign doesn't work
the way that it works, then RefRange is broken and fails at its purpose (and
this is the designer of it speaking). So, if RefRange couldn't do what it's
doing, it wouldn't exist, and no requirements have ever been place on
opAssign for ranges (in fact, for better or worse, the range API doesn't
actually require that opAssign even work for ranges, though it can certainly
be argued that it should). Now, RefRange is weird enough overall that maybe
it shouldn't exist, and it was trying to solve a problem that's not really
solvable in the general case (basically it's trying to force a range-based
function to mutate the original rather than to deal with a copy even though
the function was written to copy) - especially once forward ranges get
involved - but opAssign is doing exactly what it was intended to do, and if
what it's doing wasn't considered valid at the time, RefRange wouldn't
exist. Either way, there are times when I think that adding RefRange was a
mistake precisely because it's such an oddball and because it's only ever
really going to do what it was intended to do in some circumstances.

- Jonathan M Davis