Tracking issue for `Rc`/`Arc` stabilization

[aturon]

There are a number of unstable features related to Rc and Arc, including both weak references and uniqueness. An RFC to remove weak pointers failed, and the current consensus seems to be to stabilize these APIs after nailing down more precise semantics for uniqueness.

cc @gankro

[abonander]

Please consider #24789. Dunno if it belongs here or in the RFCs repo since it's a semantics change that wouldn't break much.

[Gankra]

Current plan:

• Stabilize weak pointers (Do we want it as a normal method? General convention is static methods -- but it's symmetric to clone)
• Stabilize try_unwrap only looking at strong count (but properly considering weak count to clean up)
• Stabilize make_unique which clones if strong != 1 || weak != 0
• Stabilize get_mut which only succeeds if strong == 1 && weak == 0
• don't stabilize is_unique because there are two notions of uniqueness (as seen above) -- can consider exposing both notions, but they're both racey to act on in Arc, I think?
• maybe stabilize strong_count and weak_count? They're harmless to support. However they're inherently racey to act on in Arc, which makes them a bit questionable.

Basically: stabilize the actually useful functionality, don't stabilize introspection pending more work.

[Gankra]

CC @SimonSapin

[Gankra]

Oh and maybe bikeshed naming? They seem perfectly cromulant to me, though make_unique has the annoying notion of uniqueness. make_mut is a potential alternative, hinting at the CoW semantics.

[Gankra]

I am currently drafting a PR to this affect.

[jethrogb]

Is alloc::arc::strong_count part of this issue or #27700?

However they're inherently racey to act on in Arc, which makes them a bit questionable.

It's not racy if you protect the Arc with a Mutex. I have a use case for this in namedlock-rs.

[Gankra]

@jethrogb this issue -- Arc is defined in liballoc but it's intended to be used inside std::sync

That issue largely concerns the actual alloc::heap API

[jethrogb]

Thanks for the clarifcation. I mention this since using it currently requires the alloc feature. Nevermind, there is the arc_counts feature as of 1.2.0.

[Gankra]

@jethrogb it only needs that feature because you're accessing the functionality through the alloc crate instead of std. The whole alloc crate is unstable to directly access.

[SimonSapin]

Of things that is still unstable but not deprecated in #27760:

• I think arc_counts methods should be deprecated since they are racy.

• Rc::is_unique with its current meaning (strong == 1 && weak == 0) can be emulated with Rc::get_mut(x).is_some(), so I don’t mind deprecating it.

• Rc::try_unwrap(x).is_ok(), however, would be destructive. I have a use case for testing Rc::strong_count(x) == 1: I want to know whether Node will be dropped when a given Rc<Node> is dropped so I can start deconstructing it to make Drop non-recursive. I could use Rc::try_unwrap, but keeping (a stack of) Rc<Node> around is much cheaper than moving Node with Rc::try_unwrap and keeping (a stack of) Node around, since Node is much larger than Rc<Node> (which is pointer-sized).

  Therefore, I don’t mind deprecating Rc::strong_count and Rc::weak_count as long as there is some way to test Rc::strong_count(x) == 1 non-destructively. Perhaps a dedicated method? But I don’t have a good name in mind, since is_unique is somewhat ambiguous.

[Gankra]

@SimonSapin sounds like all you need is would_unwrap?

[alexcrichton]

This feature is now entering its final comment period for stabilization.

I believe that @gankro will post a PR soon with various tweaks to do the final prep for stabilization