Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cuviper (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Something like this needs an API Change Proposal (ACP) - you do that by creating an issue on the libs team repo here https://github.com/rust-lang/libs-team (ACP is one of the templates).

What situation are you trying to solve exactly? (You will need to provide a motivating example in the ACP if you file one). Based on your example on the other thread, this works:

use std::cell::OnceCell;
use std::slice::Iter;

type RecordBatch = i32;

struct Foo {
    batches: OnceCell<Vec<i32>>
}

impl Foo {
    pub fn batches(&self) -> Iter<'_, RecordBatch>  {
        self.batches
            .get_or_init(|| vec![])
            .iter()
    }
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=cd3028158256e22d075a80b05dc476b8

@rustbot label +T-libs-api -T-libs
r? libs-api

this works

But the mut version is awkward:

    pub fn mut_batches(&mut self) -> IterMut<'_, RecordBatch> {
        self.batches.get_or_init(|| load_batches(&self.buf));
        // SAFETY - init above
        unsafe { self.batches.get_mut().unwrap_unchecked() }.iter_mut()
    }

Can you post a more complete version of a use case? If you're trying to repeatedly edit data behind & (rather than &mut) then you need a RefCell - RefCell<T>, RefCell<OnceCell<T>> or RefCell<Option<T>> depending on your exact needs.

Also for your example (in case it's coming from real code), I would not use unwrap_unchecked here - it's trivial for the compiler to optimize the check out. You're generally better off always using unwrap instead of unwrap_unchecked without very very good reasoning. It's safer against refactoring, and can often even wind up faster (proving preconditions for optimizations and such...)

Ah, I see your use case here https://github.com/tisonkun/kafka-api/blob/d080ab7e4b57c0ab0182e0b254333f400e616cd2/kafka-api/src/record.rs#L108-L116. It seems like you are happy with using &mut in your function signature right, and the goal is just to simplify the following?

// Old
oncecell.get_or_init(|| foobar());
oncecell.get_mut().unwrap()

// New
oncecell.get_mut_or_init(|| foobar())

That makes more sense. If you write an ACP, link it here

@tgross35 Thanks for your review! It seems an ACP is an issue at https://github.com/rust-lang/libs-team/issues/new/choose.

If so, let me try to find some time and write a formal proposal.

☔ The latest upstream changes (presumably #116742) made this pull request unmergeable. Please resolve the merge conflicts.

@tisonkun any updates on the ACP?

These methods are the equivalent of the lazycell crate's borrow_mut_with and try_borrow_mut_with, which are used by Cargo, blocking rust-lang/cargo#9310. So I am eager for this to be supported better by OnceCell.

Thanks for your reply! Let me file an ACP in this week :D

Breifly outline it here - rust-lang/libs-team#294

Looking forward to your comments and what's the next step I should do.

Could you please rebase this, and get it to compile?

OK. Let me schedule it in weeks.

@programmerjake would you possibly drop an approval or pull maintainers that can make the decision? I've tried to ask on Zulip.

Please squash this when you get the chance (still looks ok to me)

@programmerjake would you possibly drop an approval or pull maintainers that can make the decision? I've tried to ask on Zulip.

sorry, i'm not one of those who can make a decision here, @dtolnay is assigned, if they haven't responded in a month or so you might be able to use some rustbot command to pick a different assignee, though that could also make it take longer since you'd likely be at the back of that new person's queue.

@bors r+

📌 Commit 95e195f has been approved by dtolnay

It is now in the queue for this repository.

⌛ Testing commit 95e195f with merge 83d0a94...

Thanks for your review and merge @dtolnay! Two questions here:

1. How do I keep track on the following stabilize process? Is there anything that should be done by me?
2. I'd like to propose a with_extension API for PathBuf. Then I should go through a similar process to this one? (ACP, and PR)

1. After some time, a library team member will propose this for stabilization in the tracking issue (Tracking Issue for OnceCell/Lock::get_mut_or_init #121641). You should pay attention on that issue and address any design discussion that arises as people try this API in nightly.

2. That's right.