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

Should there be a Once::try_call_once #75952

Open
nbdd0121 opened this issue Aug 26, 2020 · 2 comments
Open

Should there be a Once::try_call_once #75952

nbdd0121 opened this issue Aug 26, 2020 · 2 comments
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@nbdd0121
Copy link
Contributor

nbdd0121 commented Aug 26, 2020

I wonder if Once should have a try_call_once method for failable initialization, which accepts a FnOnce() -> Result<(), E>.

OnceCell has a get_or_try_init method which can fail, so I think it would make sense for Once to have a failable initialisation method as well. Note that due to lack of failable init in Once right now, OnceCell currently need to rely on pub(crate) method to posion the Once for get_or_try_init.

cc #33577

@rustbot modify labels: +T-libs

@rustbot rustbot added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Aug 26, 2020
@Enselic Enselic added the C-discussion Category: Discussion or questions that doesn't represent real issues. label Dec 16, 2023
@MarinPostma
Copy link

I think this would be very useful for fallible, per-process initialization. How can we push this forward?

@ChrisDenton
Copy link
Member

Nowadays the best way is to create an ACP. This ensures a new API proposal will be considered by the libs-api team.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-discussion Category: Discussion or questions that doesn't represent real issues. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

5 participants