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
