Skip to content

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

peterjoel
Copy link
Contributor

@peterjoel peterjoel commented Feb 6, 2024

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.

ACP: rust-lang/libs-team#336

@rustbot
Copy link
Collaborator

rustbot commented Feb 6, 2024

r? @m-ou-se

(rustbot has picked a reviewer for you, use r? to override)

@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 Feb 6, 2024
@peterjoel peterjoel force-pushed the entry_try branch 2 times, most recently from d42817d to 007e30d Compare February 6, 2024 16:46
@Jules-Bertholet
Copy link
Contributor

Should this use the Try trait?

@peterjoel
Copy link
Contributor Author

@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>,

@peterjoel
Copy link
Contributor Author

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>,

@peterjoel
Copy link
Contributor Author

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.

@Noratrieb
Copy link
Member

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
Use @rustbot ready when your ACP has been accepeted.
@rustbot author

@rustbot rustbot added S-waiting-on-author 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 Feb 15, 2024
@peterjoel
Copy link
Contributor Author

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.

@Dylan-DPC Dylan-DPC added S-waiting-on-ACP 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 Apr 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-ACP Status: PR has an ACP and is waiting for the ACP to complete. 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.

6 participants