On Monday, April 17, 2017 18:45:46 Jerry via Digitalmars-d-learn wrote: > On Monday, 17 April 2017 at 18:07:36 UTC, Jonathan M Davis wrote: > > In this particular case, it looks like the main problem is > > RefRange's opAssign. For it to work, the type needs to be > > copyable. It might be reasonable for RefRange to be enhanced so > > that it doesn't compile in opAssign if the range isn't > > copyable, but I'd have to study RefRange in depth to know what > > the exact consequences of that would be, since it's been quite > > a while since I did anything with it. My guess is that such a > > change would be reasonable, but I don't know without studying > > it. > > > > - Jonathan M Davis > > I took a look on RefRange and the reasoning is clearly explained > in the docs like this: > > This does not assign the pointer of $(D rhs) to this $(D > RefRange). > Rather it assigns the range pointed to by $(D rhs) to the range > pointed > to by this $(D RefRange). This is because $(I any) operation on a > RefRange) is the same is if it occurred to the original range. The > exception is when a $(D RefRange) is assigned $(D null) either > or because $(D rhs) is $(D null). In that case, $(D RefRange) > longer refers to the original range but is $(D null). > > > > But what I do not understand is why this is important.
Because otherwise, it's not acting like a reference to the original range, which is the whole point of RefRange. The correct solution would probably be to @disable opAssign in the case where the original range can't be overwritten by another range. - Jonathan M Davis
