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

[WIP] Implement FusedIterator #32999

Closed
wants to merge 2 commits into from
Closed

Conversation

Stebalien
Copy link
Contributor

@Stebalien Stebalien commented Apr 15, 2016

Pending RFC rust-lang/rfcs#1581

Only implements FusedIterator for core.

/cc @bluss, @apasel422

This trait can be used to avoid the overhead of a fuse wrapper (which is pretty
high).
@rust-highfive
Copy link
Collaborator

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

#[stable(feature = "rust1", since = "1.0.0")]
impl<I> Iterator for Fuse<I> where I: Iterator {
type Item = <I as Iterator>::Item;

#[inline]
fn next(&mut self) -> Option<<I as Iterator>::Item> {
default fn next(&mut self) -> Option<<I as Iterator>::Item> {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless I'm mistaken, that doesn't apply here (yet) because we don't have the lattice rule. That is, a specialized implementation would have to have the bound I: FusedIterator + Something and the implementation on FusedIterator isn't marked default. However, that's a good point. I'll make a note of this on the specialization issue.

@hexsel
Copy link

hexsel commented Apr 16, 2016

I think the RFC link is to the wrong repo, should be rust-lang/rfcs#1581

@Stebalien
Copy link
Contributor Author

@hexsel github auto-linking... thanks.

@apasel422
Copy link
Contributor

@bors
Copy link
Contributor

bors commented Apr 22, 2016

☔ The latest upstream changes (presumably #33079) made this pull request unmergeable. Please resolve the merge conflicts.

@Stebalien
Copy link
Contributor Author

@apasel422 that certainly gets rid of the unnecessary done field which is quite nice. However having all those spec_* functions is a bit unfortunate. The future of specialization of associated types looks a bit uncertain (discussion at #33090) at the moment so I'd rather leave this implementation as-is until that gets settled.

@alexcrichton
Copy link
Member

Closing due to inactivity, but feel free to reopen once the RFC is accepted!

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.

7 participants