Must ranges support `r1 = r2;`?

[Jack Stouffer]

On Monday, 16 April 2018 at 16:22:04 UTC, Jonathan M Davis wrote:
> 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.

RefRange can be useful in certain situations. But, I don't see a 
pretty way out of this. Either

1. we break code by saying `RefRange` is doing something illegal
2. we break code by making `RefRange` always an input range
3. we change all range code which could use `opAssign` to use 
`move`, potentially breaking code which relies on opAssign being 
called, and imposing a large burden on the maintenance of 
existing code for a very small corner case. Just imagine how much 
code outside of Phobos also has this subtle bug.