Add function Arc/Rc::as_weak(…) to convert &Arc/Rc to &Weak

[jeremyBanks]

I would like to propose the addition of a new as_weak associated function on Arc and Rc, taking a shared reference to a strong Arc/Rc and transmuting it into a shared reference to the corresponding Weak type.

Currently, if you have a strong Arc/Rc and you're calling a function that expects a &Weak, you'll need to .downgrade() to create a temporary Weak, incurring two additional writes to the backing allocation. This could be avoided if it were possible to convert an &Arc/&Rc to a &Weak directly, with a function like this:

impl<T: ?Sized> Arc<T> {
    pub const fn as_weak<'a>(this: &'a Self) -> &'a Weak<T> {
        unsafe { mem::transmute::<&'a Arc<T>, &'a Weak<T>>(this) }
    }
}

In memory, Arc/Rc and sync::Weak/rc::Weak are both represented by a NotNull pointer to the backing ArcInner/RcBox where the reference counts and inner value are actually stored. Whether a reference is strong or weak exists only at the type level, and the static guarantees provided by Weak (that the pointed-to allocation will exist, unless the pointer has the special non-aligned Weak::new value) are strictly weaker than those provided by Arc/Rc (that the pointed-to allocation will exist full-stop, and that the value inside that allocation will still be valid/will not have been dropped yet). The Arc/Rc do have a PhantomData<T> that the Weaks do not, but it's zero-size and shouldn't affect layout, only drop behaviour (which isn't relevant since the proposed function is for borrowed values).

This requires the addition of the #[repr(transparent)] attribute to Arc/Rc, and Weak in order to guarantee their memory layouts are identical. (#[repr(C)] might also work for that purpose, but I'm not sure if that would break the NonZero niche optimization.) According to the discussions at #72841 (review), adding the #[repr] does not constitute a public interface change/commitment because the internal fields are still private (and with #90435 such #[repr]s may be hidden from the docs in the future). So even if the #[repr(transparent)] were added, this function still couldn't be implemented in an external crate as the crate wouldn't be able to soundly rely on the layout remaining the same; this function can only be implemented in the standard library.

This implementation is gated behind a new #![feature(rc_as_weak)].

---

previous discussion: Rust Internals thread #17171, Stack Overflow question #73314967

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[jhpratt]

Aside from needing a proper tracking issue (which shouldn't be created before this is given the okay), the diff LGTM.

[ogoffart]

struct SomeStruct(PhantomPinned);
let pinned = Rc::pin(SomeStruct(PhantomPinned));

// This is unsound !!!
let weak = Rc::as_weak(pinned.as_ref());
// ... because it would be possible to move the content of pinned:
let mut unpinned_rc = weak.upgrade().unwrap();
std::mem::drop(pinned);
// unpinned_rc is now the only reference so this will work:
let x = std::mem::replace(
    Rc::get_mut(&mut unpinned_rc).unwrap(),
    SomeStruct(PhantomPinned),
);

Edit: false alarm. This doesn't work.

[cuviper]

@ogoffart you may be still editing your example, but Pin<Rc<T>> doesn't give any access to &Rc<T>. If it did, your example of Rc::as_weak(_).upgrade() would have just the same consequences as Rc::clone(_).

[cuviper]

An interesting phenomenon is that this can let Weak::weak_count return 0, which is currently only the case when there are no strong pointers left. Nevermind that this &Weak is directly borrowed from a strong &Rc...

[ogoffart]

@cuviper ah right, my mistake. Then that's a false alarm. Sorry for the noise.

[jeremyBanks]

Weak::weak_count return 0, which is currently only the case when there are no strong pointers left

Hmm, that's a good point. I guess we could limit Weak::weak_count to return at least 1 if strong_count is at least 1 to maintain that invariant, though that sounds a bit weird.

When I have time I think I'll take a look through crates that are currently using weak_count to see if any are depending on that invariant (maybe through SourceGraph, if their index is complete).

[cuviper]

Of course, if you care about the existence of strong pointers, you can use Weak::strong_count. I don't really know what you would use Weak::weak_count for at all -- the only uses in the repo are unit tests.

The closest thing I can find is Rc's private is_unique method:

    fn is_unique(this: &Self) -> bool {
        Rc::weak_count(this) == 0 && Rc::strong_count(this) == 1
    }

but that kind of check doesn't make sense for &Weak.

[jeremyBanks]

I don't really know what you would use Weak::weak_count for at all -- the only uses in the repo are unit tests.

Looking through this crates.io package search, the uses of Weak::weak_count that I found were:

• various Arc-like types that include weak_count with other methods they're mirroring in their own interface
• unit tests for crates that use Arc and Weak
• logging it for debugging
• a few crates that check Weak::weak_count() as part of identifying or freeing items with no other weak references remaining. These instances all appear to be calling it on a Weak struct, without any way for a converted &Weak reference to end up confusing them:
  • https://sourcegraph.com/crates/hexchat-unsafe-plugin@9ece50ab15d51e1217448e93e8abb723d04878e7/-/blob/src/lib.rs?L641
  • https://sourcegraph.com/crates/crankstart@2f380a6aab8271736411262874a03f5109e2b8ce/-/blob/src/sprite.rs?L501
  • https://sourcegraph.com/crates/hakuban@8cf17cc2299618951740c1677ba007891a08b8ac/-/blob/src/node/local.rs?L96

As far as I can tell, none of these crates could be broken by this change.

[bors]

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

[m-ou-se]

For Arc, I'm not sure we should do this, because it is possible we want to use a different way of reference counting in the future where the existence of an Arc doesn't always imply an implicit Weak. For example: #116173

(For that specific algorithm we could still make it work by doing 1-2 atomic operations in as_weak, but that mostly defeats its purpose.)

For Rc, I'm not convinced having this method is worth it, since incrementing and decrementing the Weak counter is extremely cheap when not dealing with multiple threads. (I imagine the compiler might even be able to fully optimize them away in simple cases.)

[JohnCSimon]

@jeremyBanks
ping from triage - can you post your status on this PR? There hasn't been an update in a few months. Thanks!

FYI: when a PR is ready for review, send a message containing
@rustbot ready to switch to S-waiting-on-review so the PR is in the reviewer's backlog.

[Dylan-DPC]

Closing this as inactive. Feel free to reöpen this pr or create a new pr if you get the time to work on this. Thanks