Seems like your motivating example is already covered by unwrap_or_clone.

unwrap_or_clone is orthogonal – it always clones the value inside the Arc, whereas I want to clone the value held by my reference, which is not necessarily in the Arc.

Maybe I'm misunderstanding your example. Let me write out how I understand it in pseudocode:

if not ptr_eq(reference, as_ptr(arc)):
    return reference.clone()

if is_unique(arc):
    return into_inner(arc)

return reference.clone()

But since we've already established that the reference points into the arc, the last line could just as well be:

// return reference.clone()
return (*arc).clone()

And in that case, you can simply the is_unique and latter clone into:

// if is_unique(arc):
//     return into_inner(arc)
// 
// return (*arc).clone()
return unwrap_or_clone(arc)

By the time you've checked the refcounts to check if it's unique, you've already done all of the expensive stuff, so whether you clone the reference or from the arc with unwrap_or_clone makes no difference.

The entire point of my motivating example is that one can’t swap around the ptr_eq and is_unique checks like that. For example, in the multi-Arc case, it’s not ideal to have to call ptr_eq for every single Arc and store them in an array of booleans before you can attempt Arc::into_inner on the first. Though I think the limitation with Drop is more compelling:

// even if you could put this here:
if !dependent_data.depends_on(arc):
    return dependent_data.clone()

if let Some(data) = Arc::into_inner(arc):
    drop(dependent_data) // 💥: already invalidated!
    return data
else:
    return dependent_data.clone()

So I misunderstood, I didn't realize that

One implementation would be to first check whether the Arc is unique and if the &T indeed points to the Arc

meant those checks in that order.

I'm not sure if putting the checks in that specific order is sufficient to avoid UB, though. Do you have some working code using Arc::get_mut(...).is_some() that you can share?

I'm not sure if putting the checks in that specific order is sufficient to avoid UB, though. Do you have some working code using Arc::get_mut(...).is_some() that you can share?

I’m confused what UB you mean. The current UB is precisely because of get_mut invalidating references, so no, I don’t have working code – I filed this issue so I it would be possible to implement working code. The order of the checks is just for architectural and not soundness reasons, though I later realized I can’t actually change it because of the Drop problem.

I realized I was slightly confused – my description was derived from a real case in which this function is necessary, but my attempts to simplify it have made it seem trivial. In particular, even if the get_mut check is before the ptr_eq check, one does know that should the former succeed but the latter fail, the pointer was not actually invalidated since it points to a separate memory region. But my case is the general one, in which it is possible for the pointer to be invalidated even though the ptr_eq check fails.

I'm not sure if it's possible to write such a function that guarantees atomically that both the strong and weak count are 0. It would at least only be possible on platforms with double-usize atomics.

Never mind

To be clear, this function already exists – this ACP is just about making it public.

I think this proposal is needlessly restrictive. There is also the use case which I've had where you own multiple Arcs and need to guarantee that those are the only ones. And the way to solve both of our problems would be to expose something like:

impl<T, A> Arc<T, A> {
    pub fn counts(&self) -> (usize, usize) {}
}

Ensuring atomicity.

Also on a side note, if we do go with Arc::is_unique, I believe the only reason Arc::get_mut takes a mutable reference to the Arc is so that you can't get aliasing mutable references to the data. So here, it should be a shared reference for maximum flexibility IMO.

impl<T, A> Arc<T, A> {
    pub fn is_unique(&mut self) -> bool;
}

as a public API, it is strange that it takes &mut self rather than &self (or actually this: &Self because of Deref), because both Arc::{strong_count, weak_count} take this: &Self.

And the way to solve both of our problems would be to expose something like:

I’m not against this, but I think it would be good to have is_unique still as a convenience method, and to avoid the user having to write the magic number (1, 0).

I updated the proposal to use &self.

We discussed this in today's @rust-lang/libs-api meeting, and we agreed to accept this. Code searches suggest that the primary use of strong_count is to compare to 1.

Also, we discussed memory ordering, and felt that this probably warrants acquire ordering; we also felt that we should re-add the acquire ordering to strong_count as well, but that's a separate discussion.