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
