Tracking issue for RefCell::{replace, swap}

[alexcrichton]

Tracking issue for rust-lang/rfcs#2057

• Implement the functionality
• Add documentation
• Stabilize!

[notriddle]

Can I implement this? (I understand you'll want to give it the C-assigned label, to make sure nobody else works on it)

[alexcrichton]

Certainly!

[notriddle]

• Implemented the functionality
• What documentation is needed beyond the API docs?
• I assume that once 1.20 is released, we'll be able to talk about marking it stable.

[Havvy]

The only docs needed for this is the API docs.

I've also written PR #45819 to add a replace_with variant.

[gbip]

Is there any plan to make this stable ? I can't figure the syntax to move a value inside a RefCell to replace the old one.
Thanks !

[alexcrichton]

Stabilized in #46517

[SimonSapin]

replace_with was not stabilized together with replace and swap in #46517 because it wasn’t part of rust-lang/rfcs#2057.

Let’s stabilize it now, perhaps with the “corresponds to std::mem::replace” bit of doc removed per #45819 (comment)

@rfcbot fcp merge

[rfcbot]

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

• @Kimundi
• @SimonSapin
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler
• @withoutboats

Concerns:

• footgun resolved by #43570 (comment)

Once a majority of reviewers approve (and none object), 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!

See this document for info about what commands tagged team members can give me.

[alexcrichton]

@rfcbot concern footgun

I'd personally be somewhat concerned about the replace_with API in terms of the intended use case of RefCell. Used in the case where mutability doesn't cut it usage of RefCell often implies lots of aliasing all over the place which is often difficult to determine statically. As a result correct progress mostly minimize the amount of time a RefCell is borrowed or otherwise used for. I'd be worried that allowing an arbitrary closure in replace_with is hiding the fact that you're borrowing the RefCell for the duration of the entire closure. It may be clearer to force authors to explicitly take a borrow and map it to see where the borrow duration runs?

[alexcrichton]

I'm also under the impression that this isn't a massively used method in the sense that the ergonomic win here isn't necessary critical, but I could be wrong!

[Havvy]

I sent the PR for it because I wrote the function freely in my own code where I wanted to recurse through a path in a tree without passing a Vec of RefCell borrows but rather keep the borrow information in the stack.

Putting a warning that the RefCell is borrowed for the duration of the closure into the documentation would help.

[alexcrichton]

@SimonSapin do you have thoughts on the concern I listed above?

I'm not personally a huge fan of a warning in the sense that I don't think it absolves us of the footgun of the API, but if there's a strong use case for adding it then the warning is likely enough. I do not currently see, however, the strong use case for adding this

[Phlosioneer]

This has been merged. Tracking issue can be closed.

[Havvy]

RefCell::replace_with has not been stabilized yet.

[Phlosioneer]

Ah. I thought that would be a different issue, because it's not in the title and not in the RFC. Sorry.

[alexcrichton]

@rfcbot resolve footgun

I don't want to personally be on the hook for blocking this any more

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

[jonas-schievink]

Seems like this just needs a stabilization PR now?