Add Arc::into_inner for safely discarding Arcs without calling the destructor on the inner type.
#162
Labels
ACP-accepted
API Change Proposal is accepted (seconded with no objections)
api-change-proposal
A proposal to add or alter unstable APIs in the standard libraries
T-libs-api
Comments
steffahn
added
api-change-proposal
|
Seconded. Please open a tracking issue in rust-lang/rust. |
dtolnay
added
the
initial-comment-period
6 tasks
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this issue
Jan 23, 2023
…r=Mark-Simulacrum Add `Arc::into_inner` for safely discarding `Arc`s without calling the destructor on the inner type. ACP: rust-lang/libs-team#162 Reviving rust-lang#79665. I want to get this merged this time; this does not contain changes (apart from very minor changes in comments/docs). See rust-lang#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](rust-lang#106894) 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 :-)
|
The API is implemented and about to be stabilized. |
dtolnay
added
ACP-accepted
thomcc
pushed a commit
to tcdi/postgrestd
that referenced
this issue
May 31, 2023
…mulacrum Add `Arc::into_inner` for safely discarding `Arc`s without calling the destructor on the inner type. 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](rust-lang/rust#106894) 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 :-)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Proposal
Problem / Motivation / Solution
There already is a PR: rust-lang/rust#106854
Motivation
The functionality provided by this new “method” on
Arcwas previously not archievable with theArcAPI. The functioninto_inneris related totry_unwrap. The expressionArc::into_inner(x)is almost the same asArc::try_unwrap(x).ok(), however the latter includes two steps, thetry_unwrapcall and dropping theArc, whereasinto_inneraccesses theArcatomically. Since this is an issue in multi-threaded settings only, a similar function onRcis not strictly necessary but could be wanted nontheless for ergonomic and API-similarity reasons. (The existing PR currently only offers the function onArceventually adding an analogue forRccan be reasonable.)The function
Arc::into_inner(this: Arc<T>) -> Option<T>offers a way to “drop” anArcwithout calling the destructor on the contained type. When theArcprovided was the last strong pointer to its target, the target value is returned. Being able to do this is valueable around linear(-ish) types that should not or cannot just be dropped ordinarity, but require extra arguments, or operations that can fail or areasyncto properly get rid of.Rendered Documentation
Links and related work
Some time ago, there was a discussion on IRLO.
Current PR: rust-lang/rust#106854
Two previous PRs closed due to me being inactive: rust-lang/rust#79665, rust-lang/rust#75911
What happens now?
This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.
The text was updated successfully, but these errors were encountered: