On Thu, Feb 13, 2014 at 5:09 PM, Olivier Renaud <o.ren...@gmx.fr> wrote:
> 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. > This is not strictly true. If instead of fn next(&mut self) -> Option<A>; we had something like fn next(self) -> Option<(Self, A)>; then access to exhausted iterators would be ruled out at the type level. (But it's more cumbersome to work with and is currently incompatible with trait objects.) > > 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 >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev