Tricky semantics of ranges & potentially numerous Phobos bugs

[Jonathan M Davis]

On Tuesday, October 16, 2012 08:17:40 H. S. Teoh wrote:
> 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.

1. There is no generic way to deep copy stuff. So, requiring a deep copy of 
front just plain doesn't make sense. It would be completely untenable. By 
doing so, you basically make it impossible to use the result of front beyond a 
call to popFront in the general case.

2. Often, a deep copy isn't needed in the least, even with a messed up range 
like ByLine. If it were an array of class objects rather than char, doing a 
deep copy would needlessly copy all of those class objects as well. It could 
quickly become a performance nightmare.

- Jonathan M Davis