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

Improve {BTreeMap,HashMap}::get_key_value docs. #132758

Merged
merged 1 commit into from
Nov 19, 2024

Conversation

nnethercote
Copy link
Contributor

They are unusual methods. The docs don't really describe the cases when they might be useful (as opposed to just get), and the examples don't demonstrate the interesting cases at all.

This commit improves the docs and the examples.

@rustbot
Copy link
Collaborator

rustbot commented Nov 8, 2024

r? @cuviper

rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@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 Nov 8, 2024
@@ -880,7 +880,8 @@ where
self.base.get(k)
}

/// Returns the key-value pair corresponding to the supplied key.
/// Returns the key-value pair corresponding to the supplied key. This is
Copy link
Contributor

@Kobzol Kobzol Nov 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you index a hashmap, you don't actually use K for indexing, but you use Q that upholds K: Borrow<Q>. So another use-case could be that you want to inspect &K when you only have &Q, right? Like if you have &str as an indexing key for HashMap<String, T>, but you want to inspect e.g. the capacity of the &String key.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think the K/Q difference would be more interesting to demonstrate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, let me explain how this PR came about. This method has one genuine use in the compiler, in rustc_resolve. (There are three call sites which are all extremely similar.) I had never heard of this method, so I looked up the docs and found them unhelpful. After more digging I discovered that the method was being used in the way I described/demonstrated in this PR: with a type where one of the fields was being ignored.

So while I can see that the &K/&Q case is possible, the very limited real-world experience I have suggests the "ignored field" case is more interesting. "you want to inspect e.g. the capacity of the &String key" feels not that useful.

Also, I just looked through the version control history. The get_key_value methods were added in #49346, implementing the suggestion from #43143. The only justification there is "sometimes you need a reference to a key with the lifetime of the collection", which is a third motivation, but there are no actual examples and surprisingly little discussion :(

So now my inclination is to expand the text description of the methods to include the &K/&Q case and the "reference to a key with the lifetime of the collection" case, but keep the examples on the "ignore a field" case. Thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds good to me. I agree that your use-case is probably the most useful one.

They are unusual methods. The docs don't really describe the cases when
they might be useful (as opposed to just `get`), and the examples don't
demonstrate the interesting cases at all.

This commit improves the docs and the examples.
@nnethercote
Copy link
Contributor Author

@cuviper: I updated the method descriptions to cover the three cases we have discussed.

/// map.insert(j_a, "Paris");
/// assert_eq!(map.get_key_value(&j_a), Some((&j_a, &"Paris")));
/// assert_eq!(map.get_key_value(&j_b), Some((&j_a, &"Paris"))); // the notable case
/// assert_eq!(map.get_key_value(&p), None);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Muad'Dib knew that every experience carries its lesson.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Static typing is better than dynamic typing.

- Winston Churchill

@cuviper
Copy link
Member

cuviper commented Nov 18, 2024

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Nov 18, 2024

📌 Commit 2765432 has been approved by cuviper

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 Nov 18, 2024
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Nov 18, 2024
…docs, r=cuviper

Improve `{BTreeMap,HashMap}::get_key_value` docs.

They are unusual methods. The docs don't really describe the cases when they might be useful (as opposed to just `get`), and the examples don't demonstrate the interesting cases at all.

This commit improves the docs and the examples.
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 19, 2024
…llaumeGomez

Rollup of 6 pull requests

Successful merges:

 - rust-lang#132577 (Report the `unexpected_cfgs` lint in external macros)
 - rust-lang#132758 (Improve `{BTreeMap,HashMap}::get_key_value` docs.)
 - rust-lang#133180 ([rustdoc] Fix items with generics not having their jump to def link generated)
 - rust-lang#133181 (Update books)
 - rust-lang#133182 (const_panic: inline in bootstrap builds to avoid f16/f128 crashes)
 - rust-lang#133187 (Add reference annotations for diagnostic attributes)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 19, 2024
Rollup of 9 pull requests

Successful merges:

 - rust-lang#132758 (Improve `{BTreeMap,HashMap}::get_key_value` docs.)
 - rust-lang#133180 ([rustdoc] Fix items with generics not having their jump to def link generated)
 - rust-lang#133181 (Update books)
 - rust-lang#133182 (const_panic: inline in bootstrap builds to avoid f16/f128 crashes)
 - rust-lang#133185 (rustdoc-search: use smart binary search in bitmaps)
 - rust-lang#133186 (Document s390x-unknown-linux targets)
 - rust-lang#133187 (Add reference annotations for diagnostic attributes)
 - rust-lang#133191 (rustdoc book: Move `--test-builder(--wrapper)?` docs to unstable section.)
 - rust-lang#133192 (RELEASES.md: Don't document unstable `--test-build-wrapper`)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 2226541 into rust-lang:master Nov 19, 2024
6 checks passed
@rustbot rustbot added this to the 1.84.0 milestone Nov 19, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Nov 19, 2024
Rollup merge of rust-lang#132758 - nnethercote:improve-get_key_value-docs, r=cuviper

Improve `{BTreeMap,HashMap}::get_key_value` docs.

They are unusual methods. The docs don't really describe the cases when they might be useful (as opposed to just `get`), and the examples don't demonstrate the interesting cases at all.

This commit improves the docs and the examples.
@nnethercote nnethercote deleted the improve-get_key_value-docs branch November 19, 2024 19:38
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.

5 participants