-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
add perf side effect docs to Iterator::cloned()
#92955
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.
37d0146
to
d7006fe
Compare
This comment has been minimized.
This comment has been minimized.
5e9b487
to
d3227fd
Compare
This comment has been minimized.
This comment has been minimized.
d3227fd
to
516112a
Compare
/// // instead call `cloned` late: | ||
/// let good: Vec<_> = a.iter().filter(|s| s.len() == 1).cloned().collect(); | ||
/// assert_eq!(&[".".to_string()], &good[..]); | ||
/// ``` |
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.
I think this part should be fairly uncontroversial (modulo readability nits), it simply adds an implementation hint.
/// There is no guarantee whatsoever about the `clone` method actually | ||
/// being called *or* optimized away. So code should not depend on | ||
/// either. | ||
/// |
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.
This one seems a little more troublesome to me. I don't think this adds anything new, it simply makes the "no guarantee in either direction" which was previously implicit in the absence of detailed specification explicit. But some libs team members interpret API contracts differently than I do, so I want some extra eyes on this. Wait, I'm not assigned reviewer, nevermind 😅
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.
At least making it explicit allows us to point the user to the docs when they bemoan their code breaking should we ever decide to improve perf on this.
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.
I don't mind making the lack of a guarantee explicit, I don't believe this restricts us in any way which is the main thing I worry about with docs changes
516112a
to
35a6f3b
Compare
@yaahc this is waiting for review |
35a6f3b
to
1fb43f6
Compare
@bors r+ rollup=always |
📌 Commit 1fb43f6 has been approved by |
Rollup of 6 pull requests Successful merges: - rust-lang#91608 (Fold aarch64 feature +fp into +neon) - rust-lang#92955 (add perf side effect docs to `Iterator::cloned()`) - rust-lang#94713 (Add u16::is_utf16_surrogate) - rust-lang#95212 (Replace `this.clone()` with `this.create_snapshot_for_diagnostic()`) - rust-lang#95219 (Modernize `alloc-no-oom-handling` test) - rust-lang#95222 (interpret/validity: improve clarity) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Now that #90209 has been closed, as the current state of affairs is neither here nor there, this at least adds a paragraph + example on what to expect performance-wise and how to deal with it to the .cloned() docs.
cc @the8472