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.
