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

Stabilize FusedIterator #47463

Merged
merged 2 commits into from
Mar 6, 2018
Merged

Stabilize FusedIterator #47463

merged 2 commits into from
Mar 6, 2018

Conversation

bluss
Copy link
Member

@bluss bluss commented Jan 15, 2018

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 #35602

@rust-highfive
Copy link
Collaborator

r? @shepmaster

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

@bluss bluss added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Jan 15, 2018
@sfackler
Copy link
Member

This only exists for specialization right? Are we comfortable stabilizing these kinds of things before specialization itself?

@bluss
Copy link
Member Author

bluss commented Jan 15, 2018

That is the right question and I think FusedIterator does not depend on any controversial or hard part of specialization, so it seems ok.

meanwhile I can't understand what tidy wants me to fix..

@kennytm kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 16, 2018
@bluss bluss force-pushed the fused-iterator branch 2 times, most recently from 644f111 to 96e6103 Compare January 17, 2018 21:19
@bluss
Copy link
Member Author

bluss commented Jan 17, 2018

rebased to fix newer FusedIterator impls. That should fix tidy.

@sfackler
Copy link
Member

The worst case is that this becomes a slightly weird/useless trait if we have to do something drastic like roll back specialization entirely. Seems okay to stabilize I guess.

@rfcbot fcp merge

@rfcbot
Copy link

rfcbot commented Jan 18, 2018

Team member @sfackler has proposed to merge this. The next step is review by the rest of the tagged teams:

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@rfcbot rfcbot added the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Jan 18, 2018
@withoutboats
Copy link
Contributor

That is the right question and I think FusedIterator does not depend on any controversial or hard part of specialization, so it seems ok.

Maybe I don't understand how it is used, but isn't one of the main use cases essentially something like this:

trait Fuse {
    type Fused;
    fn fuse(self) -> Self::Fused;
}

impl<T: Iterator> Fuse for T { ... }

impl<T: FusedIterator> Fuse for T { ... }

This would involve specializing the associated type, which is one of the trickiest parts of specialization (because it could result in different impl instantiations at typeck time from trans time).

@bluss
Copy link
Member Author

bluss commented Jan 18, 2018

The main use is in .fused and it is method specialization only, no associated types.

Your example is interesting in itself but not what std is using now.

@bluss
Copy link
Member Author

bluss commented Jan 18, 2018

In Iterator::fuse.

@alexcrichton
Copy link
Member

Is there perhaps a "banner use case" for this trait right now? I've personally only ever seen it as a pretty niche optimization that almost never comes up in practice (I can't remember the last time I used fuse). That, coupled with the concern about specialization, gives me pause here.

I'm also pretty worried about the specialization here. If we roll it back I feel like it would be a breaking change with a trait like this. Users would use this trait only for the performance improvement (right?) and if we break that then we're effectively breaking the trait?

@bluss
Copy link
Member Author

bluss commented Jan 18, 2018

@alexcrichton .fuse() is something itertools uses a lot, so it's typical of that use case -- when we build upon iterators completely generically. For example, a.merge(b) from itertools uses .fuse() on both the component iterators.

The use case would be to implement the marker trait FusedIterator for itertools' own adaptors, where appropriate, which makes the .fuse() usages in itertools or other places much more "pay what you need" instead of paying for that extra flag check per iteration.

As a small nice thing, having FusedIterator stable would make the fusing behaviour of iterator adaptors visible and documented by their trait implementations and if/how those depend on the adapted iterator.

I think the specialization that is assumed here really is the basics and it was my impression that we are pretty certain to ship that part sooner rather than later.

@alexcrichton
Copy link
Member

@bluss ok cool thanks for the info! To clarify as well, would you consider it a breaking change if we end up later neutering the trait to not actually do anything (if specialization is removed)?

The state of specialization AFAIK is sort of "continuously in the air" where there's always a few known soundness holes with no known fixes, but there's a big chunk that's known as highly desirable and safe but unknown how to stabilize.

@bluss
Copy link
Member Author

bluss commented Jan 19, 2018

No, I can't see how it is a breaking change. We would have performance setbacks all over libcore without spec, fuse is not among the most important, and I imagine we would want other mechanisms to get the same effects. There is a risk that the trait becomes obsolete then yes if the new mechanism is not trait based.

@alexcrichton
Copy link
Member

Hm ok, if you're ok with that outcome so am I!

@kennytm kennytm added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 31, 2018
@kennytm
Copy link
Member

kennytm commented Jan 31, 2018

Triage ping, ticky boxes for you @BurntSushi!

@pietroalbini
Copy link
Member

@BurntSushi there is a nice checkbox in #47463 (comment) waiting for you!

@@ -904,5 +904,5 @@ impl<I: Iterator<Item = u8>> Iterator for DecodeUtf8<I> {
}
}

#[unstable(feature = "fused", issue = "35602")]
#[stable(feature = "fused", since = "1.25.0")]
Copy link
Member

Choose a reason for hiding this comment

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

DecodeUtf8 is still unstable so this should be #[unstable(feature = "decode_utf8", issue = "33906")].

@@ -420,5 +420,5 @@ impl<A: Step> DoubleEndedIterator for ops::RangeInclusive<A> {
}
}

#[unstable(feature = "fused", issue = "35602")]
#[stable(feature = "fused", since = "1.25.0")]
Copy link
Member

Choose a reason for hiding this comment

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

RangeInclusive is still unstable so this should be #[unstable(feature = "inclusive_range", reason = "recently added, follows RFC", issue = "28237")].

@@ -2494,7 +2494,7 @@ impl<'a, T> ExactSizeIterator for ExactChunks<'a, T> {
}
}

#[unstable(feature = "fused", issue = "35602")]
#[stable(feature = "fused", since = "1.25.0")]
Copy link
Member

Choose a reason for hiding this comment

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

ExactChunks is still unstable so this should be #[unstable(feature = "exact_chunks", issue = "47115")].

@@ -2591,7 +2591,7 @@ impl<'a, T> ExactSizeIterator for ExactChunksMut<'a, T> {
}
}

#[unstable(feature = "fused", issue = "35602")]
#[stable(feature = "fused", since = "1.25.0")]
Copy link
Member

Choose a reason for hiding this comment

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

ExactChunksMut is still unstable so this should be #[unstable(feature = "exact_chunks", issue = "47115")].

@@ -127,7 +127,7 @@ impl<I> Iterator for Utf16Encoder<I>
}
}

#[unstable(feature = "fused", issue = "35602")]
#[stable(feature = "fused", since = "1.25.0")]
Copy link
Member

Choose a reason for hiding this comment

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

Utf16Encoder is still unstable so this line can be removed.

@@ -1847,7 +1847,7 @@ impl<'a, T, P> SplitIter for RSplit<'a, T, P> where P: FnMut(&T) -> bool {
}
}

//#[unstable(feature = "fused", issue = "35602")]
//#[stable(feature = "fused", since = "1.25.0")]
Copy link
Member

Choose a reason for hiding this comment

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

RSplit is still unstable so this line can just be removed.

@@ -1906,7 +1906,7 @@ impl<'a, T, P> DoubleEndedIterator for RSplitMut<'a, T, P> where
}
}

//#[unstable(feature = "fused", issue = "35602")]
//#[stable(feature = "fused", since = "1.25.0")]
Copy link
Member

Choose a reason for hiding this comment

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

RSplitMut is still unstable so this line can just be removed.

@rfcbot
Copy link

rfcbot commented Feb 6, 2018

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Feb 6, 2018
@alexcrichton
Copy link
Member

Ok great! @bluss do you wanna address @ollie27's comments and I'll r+?

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 5, 2018
@bors
Copy link
Contributor

bors commented Mar 5, 2018

⌛ Testing commit c7c23fe with merge d9455e8a7f272c0fec238dbba7af39b560dbf2f0...

@bors
Copy link
Contributor

bors commented Mar 6, 2018

💔 Test failed - status-travis

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 6, 2018
@alexcrichton
Copy link
Member

@bors: retry

  • dist timeout :(

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 6, 2018
@bors
Copy link
Contributor

bors commented Mar 6, 2018

⌛ Testing commit c7c23fe with merge 386cd00ba6fa150f64cdae31223f5a648fcf08c4...

@bors
Copy link
Contributor

bors commented Mar 6, 2018

💔 Test failed - status-appveyor

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 6, 2018
@kennytm
Copy link
Member

kennytm commented Mar 6, 2018

@bors retry #48775

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 6, 2018
kennytm added a commit to kennytm/rust that referenced this pull request 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
bors added a commit that referenced this pull request Mar 6, 2018
Rollup of 14 pull requests

- Successful merges: #48403, #48432, #48546, #48573, #48590, #48657, #48727, #48732, #48753, #48754, #48761, #48474, #48507, #47463
- Failed merges:
@alexcrichton alexcrichton merged commit c7c23fe into rust-lang:master Mar 6, 2018
@bluss bluss deleted the fused-iterator branch March 7, 2018 20:16
@bluss
Copy link
Member Author

bluss commented Mar 7, 2018

Aw, that's quite the fight with bors. You pushed it over the finish line @alexcrichton, thank you!

kennytm added a commit to kennytm/rust that referenced this pull request Mar 15, 2018
…r=bluss

Unstabilize FusedIterator for Flatten since Flatten is unstable

PR rust-lang#47463 made `impl<I, U> FusedIterator for Flatten<I>` stable but shouldn't have since `Flatten` is still unstable. This PR makes the impl unstable again.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. relnotes Marks issues that should be documented in the release notes of the next release. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.