On 04/03/2014 14:42, Tommi wrote:
I agree that this should be an ill-behaved iterator, but my point is that according to the specification [1], this is_not_ an ill-behaved iterator, it's a completely valid one. Given that self.n is less than 10, it correctly returns some elements as Some(...) and then it returns None. After it has returned None, according to specification [1], it is allowed to return whatever it wants.
Yes, it is valid per the *current* definition of Iterator in the Rust documentation. The point of this thread is to change this definition.
Therefore I'd be inclined to say that the bug in my example is in calling fold on an iterator whose all elements have been exhausted, but that seems just silly and fragile.
Yes it’s fragile. I’m proposing the change to avoid such fragility.
[1]: The Iterator protocol states that an iterator yields a (potentially-empty, potentially-infinite) sequence of values, and returns None to signal that it's finished. The Iterator protocol does not define behavior after None is returned. A concrete Iterator implementation may choose to behave however it wishes, either by returning None infinitely, or by doing something else.
-- Simon Sapin _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
