-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Clarify documentation of slice sorting methods #85985
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
this is a @rust-lang/libs decision, so I would prefer that someone from that team review. |
library/core/src/slice/mod.rs
Outdated
/// [`Result::Err`] is returned, containing the index where a matching | ||
/// element could be inserted while maintaining sorted order. | ||
/// one of the matches could be returned. The index is chosen | ||
/// deterministically, but is subject to change between releases. If the |
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.
/// deterministically, but is subject to change between releases. If the | |
/// deterministically, but is subject to change in future versions of Rust. If the |
(Likewise for the other two comments.)
Seems reasonable to me, modulo the minor comment nit I posted (which applies to all three comments). |
@bors r+ rollup |
📌 Commit fddf012 has been approved by |
Clarify documentation of slice sorting methods After reading about [this](https://polkadot.network/a-polkadot-postmortem-24-05-2021/), I realized that although the documentation of these methods is not ambiguous in its current state, it is very easy to read it and erroneously assume that their exact behaviour can be relied upon to be deterministic. Although the docs make no guarantees about which index is returned when there are multiple matches, being more explicit about when and how their determinism can be relied upon should help prevent people from making this mistake in the future. r? `@steveklabnik`
Rollup of 11 pull requests Successful merges: - rust-lang#85906 (Use `Iterator::find` instead of open-coding it) - rust-lang#85951 (Update the documentation of `-C force-unwind-tables` for rust-lang#83482) - rust-lang#85985 (Clarify documentation of slice sorting methods) - rust-lang#85989 (Remove rustfmt tests from top-level .gitattributes) - rust-lang#86074 (Default panic message should print Box<dyn Any>) - rust-lang#86078 (Type page font weight) - rust-lang#86090 (:arrow_up: rust-analyzer) - rust-lang#86095 (Search description codeblock) - rust-lang#86096 (Comment out unused error codes and add description for E0316) - rust-lang#86101 (Correct type signature in doc for Bound::as_mut) - rust-lang#86103 (Remove lifetime hack) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
After reading about this, I realized that although the documentation of these methods is not ambiguous in its current state, it is very easy to read it and erroneously assume that their exact behaviour can be relied upon to be deterministic. Although the docs make no guarantees about which index is returned when there are multiple matches, being more explicit about when and how their determinism can be relied upon should help prevent people from making this mistake in the future.
r? @steveklabnik