Add or_try_* variants for HashMap Entry API by peterjoel · Pull Request #120708 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation7 Commits2 Checks0 Files changed
Conversation
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
[ Show hidden characters]({{ revealButtonHref }})
These methods are technically unneeded as you can implement them yourself by matching on Entry::Occupied and Entry::Vacant, but this makes it more ergonomic to use the Entry API in cases where construction of a value can fail.
I realise that the same methods can also be added to BTreeMap's Entry, but I thought I'd wait to see if this was accepted first.
r? @m-ou-se
(rustbot has picked a reviewer for you, use r? to override)
Status: Awaiting review from the assignee but also interested parties.
Relevant to the library team, which will review and decide on the PR/issue.
labels
@Jules-Bertholet You mean something like this?
pub fn or_try_insert_with<F, R>(self, default: F) -> R
where:
F: FnOnce() -> R,
R: Try<Output = V>,
Actually I think this level of genericity is not possible without HKT because the type of Try::Output is different in the return types of the default function and or_try_insert_with itself.
The default function can still have a generic return type, but I think or_try_insert_with's return type needs to be fixed as a Result.
pub fn or_try_insert_with<F, R>(self, default: F) -> Result<&'a mut V, R::Residual>
where
F: FnOnce() -> R,
R: Try<Output = V>,
My understanding of Try was out of date. In the try_trait_v2 implementation, the residual of, e..g, Result<T, E> is Result<!, E> (not E as I has assumed), and there doesn't appear to be a way to retrieve the E at either the type or value level.
@Jules-Bertholet Please let me know if I'm missing something, but I think my original signature is what we're stuck with, without larger changes to the error-handling traits.
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Thanks @Nilstrieb, I thought previously this wasn't necessary for small changes, and didn't think to check! I'll take a look at that now.
Status: PR has an ACP and is waiting for the ACP to complete.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Labels
Status: PR has an ACP and is waiting for the ACP to complete.
Relevant to the library team, which will review and decide on the PR/issue.