Skip to content
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 ambiguity in select_nth_unstable docs #119481

Merged
merged 1 commit into from
Feb 5, 2024

Conversation

romanows
Copy link
Contributor

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

@rustbot
Copy link
Collaborator

rustbot commented Dec 31, 2023

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thomcc (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

  • @rustbot author: the review is finished, PR author should check the comments and take action accordingly
  • @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

@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
@thomcc
Copy link
Member

thomcc commented Feb 1, 2024

I'm going to be away for a few months, so I'm rerolling my PRs so that folks don't have to wait for me. Sorry/thanks.

r? libs

@rustbot rustbot assigned Mark-Simulacrum and unassigned thomcc Feb 1, 2024
@Mark-Simulacrum
Copy link
Member

@bors r rollup

@bors
Copy link
Contributor

bors commented Feb 4, 2024

📌 Commit 7ac4515 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

@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
…iaskrgr

Rollup of 9 pull requests

Successful merges:

 - rust-lang#119481 (Clarify ambiguity in select_nth_unstable docs)
 - rust-lang#119600 (Remove outdated references to librustc_middle)
 - rust-lang#120458 (Document `&CStr` to `CString` conversion)
 - rust-lang#120569 (coverage: Improve handling of function/closure spans)
 - rust-lang#120572 (Update libc to 0.2.153)
 - rust-lang#120587 (miri: normalize struct tail in ABI compat check)
 - rust-lang#120607 (fix rust-lang#120603 by adding a check in default_read_buf)
 - rust-lang#120636 (Subtree update of `rust-analyzer`)
 - 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 bors merged commit 7158b3d into rust-lang:master Feb 5, 2024
11 checks passed
@rustbot rustbot added this to the 1.78.0 milestone 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*".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants