Tricky semantics of ranges & potentially numerous Phobos bugs

[H. S. Teoh]

On Tue, Oct 16, 2012 at 05:01:57PM +0200, Tommi wrote:
> On Tuesday, 16 October 2012 at 05:49:11 UTC, Jonathan M Davis wrote:
> >So, I don't really know what the right answer is, but I _really_
> >don't like the idea of having to worry about the result of front
> >changing after a call to popFront in every single function that ever
> >uses front.
> 
> Isn't the deeper underlying problem here the fact that there's no
> generic way to make a deep copy in this language (does any language?)
> Making a deep copy of front would be a clean solution. I don't know
> how to implement this generic deep copying functionality though. For
> example: what would be the semantics of deep-copying a range?

I don't think the problem here is whether we have a deep copy or not,
but that the semantics of ranges are not defined clearly enough. If we
clearly state, for example, that whatever is returned by .front must
persist beyond popFront(), then it would be up to the range to implement
the deep copy, e.g., return the .dup or .idup'd array instead of a
reference to an internal buffer.

OTOH, if we clearly state that .front may not persist past the next
popFront(), then it would be up to the caller to .dup the return value,
or otherwise make a safe copy of it (or use the value before calling
popFront()).

The current ambiguous situation leads to one range doing one thing, and
another range doing something else, and either way, either this code
will break or that code will break.


T

-- 
"Holy war is an oxymoron." -- Lazarus Long