Skip to content

Conversation

@kpreid
Copy link
Contributor

@kpreid kpreid commented Nov 6, 2025

Per #148486 (comment)

In Option::get_or_insert_with(), after replacing the None with Some, forget the None instead of dropping it.

This allows eliminating the T: [const] Destruct bounds, making the functions more flexible in (unstable) const contexts, and avoids generating an implicit drop_in_place::<Option<T>>() that will never do anything (and which might even persist after optimization).

…ing it.

This allows eliminating the `T: [const] Destruct` bounds and avoids
generating an implicit `drop_in_place::<Option<T>>()` that will never do
anything.

Ideally, the compiler would prove that that drop is not necessary
itself, but it currently doesn't, even with `const_precise_live_drops`
enabled.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Nov 6, 2025
@rustbot
Copy link
Collaborator

rustbot commented Nov 6, 2025

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@kpreid
Copy link
Contributor Author

kpreid commented Nov 6, 2025

cc @cyb0124 (this change is based on their idea)

Comment on lines +498 to +501
/// Test that `Option::get_or_insert_*` are usable in const contexts, including with types that
/// do not have `const Drop` (except for [`Option::get_or_insert()`], which is not const).
#[test]
fn option_const_get_or_insert() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe split this test such that we can use a more unambiguous name don't have to mention an exception.

Comment on lines +1819 to +1820
// It could also be expressed as `core::ptr::write(self, Some(f()))`; that would be
// additional unsafe code, so should be avoided unless a reason is found.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe include the unsafe block inside the code example?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants