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.

Reply via email to