Stabilize core::mem::DropGuard - #161520
Conversation
rustbot
added
S-waiting-on-review
|
@rfcbot fcp merge libs |
|
@nia-e has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rust-rfcbot
added
proposed-final-comment-period
|
The feedback in #144426 (comment) / alternative in #150027 may not have been discussed by the team. I would be open to something like #161550 to make no-value DropGuard feel more like a first class use case. |
|
@dtolnay The question of whether to add an additional constructor which doesn't take a value was discussed during a previous libs call in the context of rust-lang/libs-team#629. Highlighting the relevant section from @Amanieu's comment in rust-lang/libs-team#629 (comment):
That's not a definitive "no" — but it has at least been considered before, and at least at the time didn't seem like a worthwhile addition. |
|
Per the meeting we were pretty fine with this API and its use case and didn't feel the other version needed to block it. Honestly feels like it could be a separate type given the API simplicity. |
…they
Use `drop_guard` in some places in {core,alloc,std}
- Tracking issue: rust-lang#144426
- Will conflict with rust-lang#161520
- rust-lang#161550 would also be cool occasionally
Didn't touch the places where manual `impl Drop`s had `#[inline]` on their `fn drop` or where the guard type had other `impl`s beside `Drop` and/or was named a lot.
No LLMs used, only pure human slop.
|
Quoting my own comment on #161550 (comment):
I believe the only decision blocking the |
6 participants
Closes #144426. This PR stabilizes
core::mem::DropGuard, as per the comment in #144426 (comment):Thanks!
r? @nia-e