-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Add or_try_*
variants for HashMap Entry API
#120708
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
base: master
Are you sure you want to change the base?
Conversation
r? @m-ou-se (rustbot has picked a reviewer for you, use r? to override) |
d42817d
to
007e30d
Compare
Should this use the |
@Jules-Bertholet You mean something like this?
|
Actually I think this level of genericity is not possible without HKT because the type of The default function can still have a generic return type, but I think
|
My understanding of @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. |
Thank you for the PR! This PR contains a public library API change, which should follow the proper process of creating an ACP first: https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html |
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. |
These methods are technically unneeded as you can implement them yourself by matching on
Entry::Occupied
andEntry::Vacant
, but this makes it more ergonomic to use theEntry
API in cases where construction of a value can fail.I realise that the same methods can also be added to
BTreeMap
'sEntry
, but I thought I'd wait to see if this was accepted first.ACP: rust-lang/libs-team#336