As you said, the type system can not enforce this rule, that's why the documentation have no choice but to say the behavior is undefined.
If the code you write relies on None being returned forever, then you should use the Fuse iterator adaptor, that wraps an existing iterator and enforces this behavior: http://static.rust-lang.org/doc/master/std/iter/trait.Iterator.html#method.fuse http://static.rust-lang.org/doc/master/guide-container.html#iterator-adaptors ----- Message d'origine ----- De : Simon Sapin Envoyés : 13.02.14 16:05 À : rust-dev@mozilla.org Objet : [rust-dev] RFC: Conventions for "well-behaved" iterators Hi, The Rust documentation currently makes iterators behavior undefined after .next() has returned None once. http://static.rust-lang.org/doc/master/std/iter/trait.Iterator.html > 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. http://static.rust-lang.org/doc/master/guide-container.html > In general, you cannot rely on the behavior of the next() method > after it has returned None. Some iterators may return None forever. > Others may behave differently. This is unfortunate. Code that accepts any iterator as input and does with it anything more complicated than a single 'for' loop will have to be defensive in order to not fall into undefined behavior. The type system can not enforce anything about this, but I’d like that we consider having conventions about "well-behaved" iterators. --- Proposal: 0. An iterator is said to be "well-behaved" if, after its .next() method has returned None once, any subsequent call also returns None. 1. Iterators *should* be well-behaved. 2. Iterators in libstd and other libraries distributed with rustc *must* be well-behaved. (I.e. not being well-behaved is a bug.) 3. When accepting an iterator as input, it’s ok to assume it’s well-behaved. 4. For iterator adaptors in particular, 3. means that 1. and 2. only apply for well-behaved input. (So that, eg. std::iter::Map can stay as straightforward as it is, and does not need to be coded defensively.) --- Does the general idea sound like something y’all want? I’m not overly attached to the details. -- Simon Sapin _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
