Le 16/10/2012 15:30, H. S. Teoh a écrit :
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
The default semantic should be the safe one.
Providing backdoor for experienced developer is useful, but it does arm
as default behavior.
