Clarify ambiguity in select_nth_unstable docs by romanows · Pull Request #119481 · rust-lang/rust

@romanows

@rustbot rustbot added S-waiting-on-review

Status: Awaiting review from the assignee but also interested parties.

T-libs

Relevant to the library team, which will review and decide on the PR/issue.

labels

Dec 31, 2023

@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

Feb 4, 2024

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*".

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

bors added a commit to rust-lang-ci/rust that referenced this pull request

Feb 5, 2024

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

Feb 5, 2024
Rollup 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*".