Skip to content

Tracking Issue for OnceCell/Lock::get_mut_or_init #121641

Open

Description

@tisonkun

Feature gate: #![feature(once_cell_get_mut)]

This is a tracking issue for

  • OnceCell::get_mut_or_init()
  • OnceCell::get_mut_or_try_init()
  • OnceLock::get_mut_or_init()
  • OnceLock::get_mut_or_try_init()

Public API

    pub fn get_mut_or_try_init<F, E>(&mut self, f: F) -> Result<&mut T, E>
    where
        F: FnOnce() -> Result<T, E> { ... }

    pub fn get_mut_or_init<F>(&mut self, f: F) -> &mut T
    where
        F: FnOnce() -> T { ... }

Steps / History

Unresolved Questions

None yet.

Footnotes

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

Activity

  1. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Feb 26, 2024
  2. ChayimFriedman2 commented on Jul 7, 2024

    @ChayimFriedman2
    Contributor

    The documentation seems wrong?

    Many threads may call get_mut_or_init concurrently with different initializing functions, but it is guaranteed that only one function will be executed.

    Since it takes &mut self, this is entirely impossible.

    The implementation can likewise be simplified a lot by not using any synchronization.

  3. added a commit that references this issue on Jul 31, 2024
  4. added a commit that references this issue on Aug 1, 2024
  5. tisonkun commented on Jan 30, 2026

    @tisonkun
    ContributorAuthor

    @dtolnay Shall we have an FCP for this feature? I encounter this requriement in stable toolchain today again :P

  6. dtolnay commented on Jan 30, 2026

    @dtolnay
    Member

    I doubt that get_mut_or_try_init can be stabilized sooner than #109737.

    That tracking issue has an unresolved question around core::ops::Try.

  7. dtolnay commented on Jan 30, 2026

    @dtolnay
    Member

    This and #109737 can be stabilized together if we are going to keep Result in all the signatures (which is my preference).

    @rfcbot merge libs-api

  8. rust-rfcbot commented on Jan 30, 2026

    @rust-rfcbot
    Collaborator

    @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

    No concerns currently listed.

    Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    cc @rust-lang/libs-ping: FCP proposed for libs, please feel free to register concerns.
    See this document for info about what commands tagged team members can give me.

  9. added
    proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
    disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.
    on Jan 30, 2026
  10. coastalwhite commented on Apr 17, 2026

    @coastalwhite
    Contributor

    Bumping this as this only needs 1 more vote to enter the FCP. This would allow a few libraries to move off once_cell.

  11. added
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    and removed
    T-libs-api[DEPRECATED; DO NOT USE]
    on Aug 12, 2026
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-libsRelevant to the library team, which will review and decide on the PR/issue.disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions