Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initial iterator object library #5810

Merged
merged 1 commit into from
Apr 13, 2013
Merged

initial iterator object library #5810

merged 1 commit into from
Apr 13, 2013

Conversation

thestinger
Copy link
Contributor

The current protocol is very comparable to Python, where .__iter__() returns an iterator object which implements .__next__() and throws StopIteration on completion. Option is much cleaner than using a exceptions as a flow control hack though. It requires that the container is frozen so there's no worry about invalidating them.

Advantages over internal iterators, which are functions that are passed closures and directly implement the iteration protocol:

  • Iteration is stateful, so you can interleave iteration over arbitrary containers. That's needed to implement algorithms like zip, merge, set union, set intersection, set difference and symmetric difference. I already used this internally in the TreeMap and TreeSet implementations, but regions and traits weren't solid enough to make it generic yet.
  • They provide a universal, generic interface. The same trait is used for a forward/reverse iterator, an iterator over a range, etc. Internal iterators end up resulting in a trait for each possible way you could iterate.
  • They can be composed with adaptors like ZipIterator, which also implement the same trait themselves.

The disadvantage is that they're a pain to write without support from the compiler for compiling something like yield to a state machine. :)

This can coexist alongside internal iterators since both can use the current for protocol. It's easier to write an internal iterator, but external ones are far more powerful/useful so they should probably be provided whenever possible by the standard library.

Current issues

#5801 is somewhat annoying since explicit type hints are required.

I just wanted to get the essentials working well, so I haven't put much thought into making the naming concise (free functions vs. static new methods, etc.).

Making an Iterable trait seems like it will have to be a long-term goal, requiring type system extensions. At least without resorting to objects which would probably be unacceptably slow.

bors added a commit that referenced this pull request Apr 13, 2013
The current protocol is very comparable to Python, where `.__iter__()` returns an iterator object which implements `.__next__()` and throws `StopIteration` on completion. `Option` is much cleaner than using a exceptions as a flow control hack though. It requires that the container is frozen so there's no worry about invalidating them.

Advantages over internal iterators, which are functions that are passed closures and directly implement the iteration protocol:

* Iteration is stateful, so you can interleave iteration over arbitrary containers. That's needed to implement algorithms like zip, merge, set union, set intersection, set difference and symmetric difference. I already used this internally in the `TreeMap` and `TreeSet` implementations, but regions and traits weren't solid enough to make it generic yet.
* They provide a universal, generic interface. The same trait is used for a forward/reverse iterator, an iterator over a range, etc. Internal iterators end up resulting in a trait for each possible way you could iterate.
* They can be composed with adaptors like `ZipIterator`, which also implement the same trait themselves.

The disadvantage is that they're a pain to write without support from the compiler for compiling something like `yield` to a state machine. :)

This can coexist alongside internal iterators since both can use the current `for` protocol. It's easier to write an internal iterator, but external ones are far more powerful/useful so they should probably be provided whenever possible by the standard library.

## Current issues

#5801 is somewhat annoying since explicit type hints are required.

I just wanted to get the essentials working well, so I haven't put much thought into making the naming concise (free functions vs. static `new` methods, etc.).

Making an `Iterable` trait seems like it will have to be a long-term goal, requiring type system extensions. At least without resorting to objects which would probably be unacceptably slow.
@bors bors closed this Apr 13, 2013
@bors bors merged commit 8bf9fc5 into rust-lang:incoming Apr 13, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Jul 17, 2020
fix typos (found by codespell)

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants