Add or_try_* variants for HashMap Entry API#120708
Add or_try_* variants for HashMap Entry API#120708peterjoel wants to merge 2 commits intorust-lang:mainfrom
or_try_* variants for HashMap Entry API#120708Conversation
|
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::OccupiedandEntry::Vacant, but this makes it more ergonomic to use theEntryAPI 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