Tracking issue for RFC 1789: Conversions from &mut T to &Cell<T>

[aturon]

This is a tracking issue for the RFC "Conversions from &mut T to &Cell<T>" (rust-lang/rfcs#1789).

Steps:

• Implement the RFC
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

[bstrie]

This appears to have been implemented and is sitting behind the as_ref feature flag. Would anyone like to make any motions toward stabilization, or did the long discussion in the implementation PR cast doubts on the design?

[SimonSapin]

Let’s.

@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:

• @Amanieu
• @BurntSushi
• @Kimundi
• @KodrAus
• @SimonSapin
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler
• @withoutboats

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!

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

[dtolnay]

As I understand it, the new API here currently consists of:

impl<T: ?Sized> Cell<T> {
    pub fn from_mut(t: &mut T) -> &Cell<T>;
}

impl<T> Cell<[T]> {
    pub fn as_slice_of_cells(&self) -> &[Cell<T>];
}

[czipperz]

Ping @BurntSushi @aturon @withoutboats do any of you have any concerns with merging this?

[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.

[SimonSapin]

Stabilization PR: #61620

[SimonSapin]

Stabilized in #61620.

[czipperz]

Does someone want to edit the description to check the stabilization checkbox?

[SimonSapin]

Sure, though IMO the issue being closed already reflects that everything in it is either done or obsolete.

[jethrogb]

Why doesn't this return &mut Cell<T>?

[SimonSapin]

Is there a case where this would be useful? I feel that having multiple references to the thing is the point of this API.

[jethrogb]

You can trivially convert a &mut Cell<T> to a &Cell<T> and then hand out multiple references. Also, it's too late now because 1.37 has been released.

[czipperz]

Is there a way to go from &mut Cell<T> to &mut T?

[jethrogb]

https://doc.rust-lang.org/std/cell/struct.Cell.html#method.get_mut

[czipperz]

So that's the reason why this should return &mut Cell<T> imo.

[SimonSapin]

This discussion is somewhat academic since Cell::from_mut is now stable on the stable channel, but:

• If you’re gonna convert to &Cell<T> anyway, why would it be useful (rather than merely not an obstacle) for Cell::from_mut to return &mut Cell<T>?
• If you’re gonna call Cell::get_mut on the result, why is it useful to go through Cell::from_mut in the first place? &mut T is what you started from.

[czipperz]

I see what you mean. This is a tool for allowing temporary usage through a &Cell<T> for single thread scoped shared state. But the long term storage solution should be &mut T. I guess this api limits people to not store &mut Cell<T> that points to &mut T. But I don't know how useful that is in reality.