-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Enable draining iterator/stream elements into a ()
#94166
Conversation
r? @yaahc (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
c0af23b
to
a54a6b4
Compare
This comment has been minimized.
This comment has been minimized.
a54a6b4
to
d1e444d
Compare
This might affect inference in cases like: struct Baz;
impl Into<()> for Baz {
fn into(self) -> () { () }
}
impl Into<i32> for Baz {
fn into(self) -> i32 { 0 }
}
fn main() {
let _: () = vec![Baz].into_iter().map(|b| b.into()).collect();
} |
iter.into_iter().for_each(|()| {}) | ||
impl<T> FromIterator<T> for () { | ||
fn from_iter<A: IntoIterator<Item = T>>(iter: A) -> Self { | ||
iter.into_iter().for_each(|_| {}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iter.into_iter().for_each(|_| {}) | |
iter.into_iter().for_each(drop) |
Maybe this should also use .for_each(drop)
to clarify the intent better? It doesn't matter much for ()
, but for generic T
that seems better.
What is the motivating use case for this PR? To me |
The use case I ran into was running an iterator completion, stopping on the first error, but not caring about the success type. |
I think I understand what you mean but the example you gave is a little confusing. You mentioned stopping on the first error but then the snippet shows a Regardless, In this case I'd still prefer to push people towards the explicit case. I don't think that collecting into cc @scottmcm |
Yes, sorry, I meant |
And in the case where you drop there's no need to collect it into a |
Right, yes, |
I still think that breaking inference is a concern, and possibly does not outweigh the convenience of not having to map the elements under drop. I guess we could do crater to check if there are people actually using the |
I've never really been a fan of this, going back to even when it was first added: #45379 (comment) I can accept it for But when actually throwing stuff away, I think rust/library/core/src/iter/traits/iterator.rs Line 1783 in c102c5c
So like #64117 (comment), I'd propose just closing this with reference to #48945 (comment). |
@scottmcm I think this case is slightly different from those because it is simultaneously dropping the iter.try_for_each(|r| {
let _ = r?;
Ok(())
})?; I agree with wanting to close this though, especially given that this is an insta-stable change. @ibraheemdev I appreciate the work you've put into this, but I don't think we should add this change to the standard library. I'm going to close this for now. If additional reasons come up, or additional information changes some of these conclusions, we can always reopen this PR. Regardless, thank you for your work. |
The current implementation of
Extend
for()
was added in #50234 because:Making the implementation generic makes something like
stream.collect::<()>
possible for any stream, vs.stream.map(drop).collect::<()>
.Similarly,
impl<T> FromIterator<T> for ()
makesiter.collect::<()>
a generic replacement foriter.for_each(drop)
.