Clarify ambiguity in select_nth_unstable docs by romanows · Pull Request #119481 · rust-lang/rust
rustbot
added
S-waiting-on-review
labels
Dec 31, 2023
bors
added
S-waiting-on-bors
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.labels
Feb 4, 2024matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Feb 4, 2024…le, r=Mark-Simulacrum Clarify ambiguity in select_nth_unstable docs Original docs for `select_nth_unstable` family of functions were ambiguous as to whether "the element at `index`" was the element at `index` before the function reordered the elements or after the function reordered the elements. The most helpful change in this PR is to change the given examples to make this absolutely clear. Before, "the element at `index`" was the same value before and after the reordering, so it didn't help disambiguate the meaning. I've changed the example for `select_nth_unstable` and `select_nth_unstable_by` so that "the element at `index`" is different before and after the reordering, which clears up the ambiguity. The function `select_nth_unstable_by_key` already had an example that was unambiguous. In an attempt to clear up the ambiguity from the get-go, I've added a bit of redundancy to the text. Now the docs refer to "the element at `index` *after the reordering*".
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request
Feb 4, 2024…le, r=Mark-Simulacrum Clarify ambiguity in select_nth_unstable docs Original docs for `select_nth_unstable` family of functions were ambiguous as to whether "the element at `index`" was the element at `index` before the function reordered the elements or after the function reordered the elements. The most helpful change in this PR is to change the given examples to make this absolutely clear. Before, "the element at `index`" was the same value before and after the reordering, so it didn't help disambiguate the meaning. I've changed the example for `select_nth_unstable` and `select_nth_unstable_by` so that "the element at `index`" is different before and after the reordering, which clears up the ambiguity. The function `select_nth_unstable_by_key` already had an example that was unambiguous. In an attempt to clear up the ambiguity from the get-go, I've added a bit of redundancy to the text. Now the docs refer to "the element at `index` *after the reordering*".
bors added a commit to rust-lang-ci/rust that referenced this pull request
Feb 5, 2024…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#119481 (Clarify ambiguity in select_nth_unstable docs) - rust-lang#120384 (Use `<T, U>` for array/slice equality `impl`s) - rust-lang#120423 (update indirect structural match lints to match RFC and to show up for dependencies) - rust-lang#120458 (Document `&CStr` to `CString` conversion) - rust-lang#120558 (Stop bailing out from compilation just because there were incoherent traits) - rust-lang#120572 (Update libc to 0.2.153) - rust-lang#120641 (rustdoc: trait.impl, type.impl: sort impls to make it not depend on serialization order) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Feb 5, 2024Rollup merge of rust-lang#119481 - romanows:fix-doc-select-nth-unstable, r=Mark-Simulacrum Clarify ambiguity in select_nth_unstable docs Original docs for `select_nth_unstable` family of functions were ambiguous as to whether "the element at `index`" was the element at `index` before the function reordered the elements or after the function reordered the elements. The most helpful change in this PR is to change the given examples to make this absolutely clear. Before, "the element at `index`" was the same value before and after the reordering, so it didn't help disambiguate the meaning. I've changed the example for `select_nth_unstable` and `select_nth_unstable_by` so that "the element at `index`" is different before and after the reordering, which clears up the ambiguity. The function `select_nth_unstable_by_key` already had an example that was unambiguous. In an attempt to clear up the ambiguity from the get-go, I've added a bit of redundancy to the text. Now the docs refer to "the element at `index` *after the reordering*".
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters