Skip to content

FusedIterator marker trait for iter::Fuse specialization #35602

New issue

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

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

Already on GitHub? # to your account

Closed
alexcrichton opened this issue Aug 11, 2016 · 2 comments
Closed

FusedIterator marker trait for iter::Fuse specialization #35602

alexcrichton opened this issue Aug 11, 2016 · 2 comments
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@alexcrichton
Copy link
Member

Tracking issue for rust-lang/rfcs#1581

@alexcrichton alexcrichton added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Aug 11, 2016
Stebalien added a commit to Stebalien/rust that referenced this issue Aug 18, 2016
This trait can be used to avoid the overhead of a fuse wrapper when an iterator
is already well-behaved.

Conforming to: RFC 1581
Closes: rust-lang#35602
bors added a commit that referenced this issue Aug 23, 2016
Implement 1581 (FusedIterator)

* [ ] Implement on patterns. See #27721 (comment).
* [ ] Handle OS Iterators. A bunch of iterators (`Args`, `Env`, etc.) in libstd wrap platform specific iterators. The current ones all appear to be well-behaved but can we assume that future ones will be?
* [ ] Does someone want to audit this? On first glance, all of the iterators on which I implemented `FusedIterator` appear to be well-behaved but there are a *lot* of them so a second pair of eyes would be nice.
* I haven't touched rustc internal iterators (or the internal rand) because rustc doesn't actually call `fuse()`.
* `FusedIterator` can't be implemented on `std::io::{Bytes, Chars}`.

Closes: #35602 (Tracking Issue)
Implements: rust-lang/rfcs#1581
@leoyvens
Copy link
Contributor

Are tracking issues for unstable features supposed to be closed? Shouldn't this be reopened pending FusedIterator stabilization?

@alexcrichton alexcrichton reopened this Sep 26, 2016
@alexcrichton
Copy link
Member Author

Indeed, thanks @leodasvacas!

@alexcrichton alexcrichton added B-unstable Blocker: Implemented in the nightly compiler and unstable. and removed B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. labels Sep 26, 2016
@Mark-Simulacrum Mark-Simulacrum added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Jul 22, 2017
kennytm added a commit to kennytm/rust that referenced this issue Mar 6, 2018
Stabilize FusedIterator

FusedIterator is a marker trait that promises that the implementing
iterator continues to return `None` from `.next()` once it has returned
`None` once (and/or `.next_back()`, if implemented).

The effects of FusedIterator are already widely available through
`.fuse()`, but with stable `FusedIterator`, stable Rust users can
implement this trait for their iterators when appropriate.

Closes rust-lang#35602
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants