On Mon, Oct 15, 2012 at 10:59:26PM -0700, Jonathan M Davis wrote: > On Monday, October 15, 2012 22:48:15 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. In the general case, I just don't see how that's > > tenable. I'd _much_ rather that it be up to the programmer using > > abnormal ranges such as ByLine to use them correctly. > > And actually, it seems to me that issues like this make it look like > it was a mistake to make ranges like ByLine ranges in the first place. > They should have just defined opApply so that they'd work nicely in > foreach but not with range- based functions. They're clearly not going > to work with a _lot_ of range-based functions. [...]
But nothing about the definition of a range, as currently defined in std.range, guarantees that whatever value was returned by .front is still valid after popFront() is called. I'm not saying that this should be the "correct" behaviour, but the current definition does not prohibit a range from, say, reusing an array to compute its next element. For example, one may have a range that returns the permutations of a given array, in which popFront() permutes the elements in-place. In this case, .front will become invalid once popFront() is called. Many of the current range-based functions will not work correctly in this case. Of course, it's arguable whether such ranges should be admissible, but as far as the current definition goes, I don't see anything that states otherwise. If we don't make such things clear, then we're bound to run into pathological cases where bugs will creep in because of unstated assumptions in the code. T -- Fact is stranger than fiction.
