Skip to content

Tracking Issue for once_cell_try #109737

Open
Listed in
Open
@tgross35

Description

@tgross35
Contributor

This supercedes #74465 after a portion of once_cell was stabilized with #105587

Feature gate: #![feature(once_cell_try)]

This is a tracking issue for the *try* methods that go with the once_cell feature. Initially they were part of stabilization under once_cell (#105587) but was removed due to compatibility concerns with try trait v2 (#105587 (comment)).

Public API

impl<T> OnceCell<T> {
    pub fn get_or_try_init<F, E>(&self, f: F) -> Result<&T, E> where F: FnOnce() -> Result<T, E>;
}

impl<T> OnceLock<T> {
    pub fn get_or_try_init<F, E>(&self, f: F) -> Result<&T, E> where F: FnOnce() -> Result<T, E>;
}

Steps / History

Unresolved Questions

  • None yet.

cc @joboet @matklad just for reference

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html

Activity

added
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.
on Mar 29, 2023
BurntSushi

BurntSushi commented on Mar 30, 2023

@BurntSushi
Member

I think I'd say that the question of whether to make the fallible routines generic over Try is unresolved at this point. See: #107122 (comment) and #84277 (comment)

tgross35

tgross35 commented on Mar 30, 2023

@tgross35
ContributorAuthor

I'm kind of curious of how and how often these functions are used in the ecosystem, does anyone know of any examples? They're not used anywhehre in rustc

BurntSushi

BurntSushi commented on Mar 30, 2023

@BurntSushi
Member

I posted a comment on that PR with the results of a quick search that I did: #107122 (comment)

sutes-work

sutes-work commented on Feb 22, 2024

@sutes-work

Related to this, I want something like: TryLazyLock. Not sure if this is the right place to comment (sorry if it's not!).

I looked to see how get_or_try_init is implemented, but unfortunately, the poison method on Once isn't exposed publicly. It would be nice of Once had an API that would support this.

tgross35

tgross35 commented on Feb 22, 2024

@tgross35
ContributorAuthor

@sutes-work can you give an example of what a TryLazyLock API would do differently from get_or_try_init?

sutes-work

sutes-work commented on Feb 22, 2024

@sutes-work

So I can do this:

struct TryLazyLock<T, F> {
    data: OnceLock<T>,   
    init_fn: UnsafeCell<Option<F>>,
}

and it's not so bad, but it costs me space for the init_fn. I should be able to share that space with T. I should be able to have:

struct TryLazyLock<T, F> {
    once: Once,
    value: UnsafeCell<State<T, F>>,
}

enum State {
   PreInit(F),
   Complete(T)
}

It's a bit rough, but hopefully you get the idea.

32 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @alex@briansmith@BurntSushi@matklad@tgross35

        Issue actions

          Tracking Issue for `once_cell_try` · Issue #109737 · rust-lang/rust