Add Arc::into_inner for safely discarding Arcs without calling the destructor on the inner type.

[steffahn]

ACP: rust-lang/libs-team#162

Reviving #79665.

I want to get this merged this time; this does not contain changes (apart from very minor changes in comments/docs).

See #79665 for further description of the PR. The only “unresolved” points that led to that PR being closed, AFAICT, were

• The desire to also implement a Rc::into_inner function
  • however, this can very well also happen as a subsequent PR
• Possible need for further discussion on the naming “into_inner” (?)
  • into_inner seems fine to me; also, this PR introduces unstable API, and names can be changed later, too
• I don't know if a tracking issue for the feature flag is supposed to be opened before or after this PR gets merged (if before, then I can add the issue number to the #[unstable…] attribute) There is a tracking issue now.

I say “unresolved” in quotation marks because from my point of view, if reviewers agree, the PR can be merged immediately and as-is :-)

[rustbot]

r? @Mark-Simulacrum

(rustbot 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

[steffahn]

@rustbot label +T-libs-api -T-libs

[steffahn]

ACP… that’s something new o.O

So I should open an ACP issue? I’d just copy the bottom section from #79665 with a new render of the documentation.

[m-ou-se]

ACP… that’s something new o.O

Yeah that's something new we're trying out to separate the 'should we have this' discussion from the implementation review. (And to allow that discussion to happen before the implementation, in case you don't want to risk implementing something that won't be accepted.)

[steffahn]

Added a remark as suggested in #79665 (comment)

[Mark-Simulacrum]

r=me with commits squashed, thanks!

[steffahn]

squashed

[Mark-Simulacrum]

@bors r+

[bors]

📌 Commit 33696fa has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[kvark]

@steffahn congratulations to this being landed and stabilizing!
I find the functionality much needed. However, it misses one important case - what to do with Sized? types.
We'd very much still want this property to hold:

If Arc::into_inner is called on every clone of this Arc, it is guaranteed that exactly one of the calls returns the inner value. This means in particular that the inner value is not dropped.

Except that for the unsized types, only one call to a function will succeed, but it will not be able to return the inner value.
I considered the alternatives, and I don't think there is anything to help with this right now:

• Arc::into_inner is only for T: Sized
• Arc::get_mut isn't dropping, therefore multiple such arcs can return None if checked before destruction.

Maybe I'm missing something? Or maybe this discussion has already happened somewhere, excuse me for not finding it!