Tracking issue for const Option functions

[9999years]

Current candidates with feature = const_option:

impl<T> Option<T> {
    pub const fn as_mut(&mut self) -> Option<&mut T>;
    pub const fn expect(self, msg: &str) -> T;
    pub const fn unwrap(self) -> T;
    pub const unsafe fn unwrap_unchecked(self) -> T;
    pub const fn take(&mut self) -> Option<T>;
    pub const fn replace(&mut self, value: T) -> Option<T>;
}

impl<T> Option<&T> {
    pub const fn copied(self) -> Option<T>
    where
        T: Copy;
}

impl<T> Option<&mut T> {
    pub const fn copied(self) -> Option<T>
    where
        T: Copy;
}

impl<T, E> Option<Result<T, E>> {
    pub const fn transpose(self) -> Result<Option<T>, E>
}

impl<T> Option<Option<T>> {
    pub const fn flatten(self) -> Option<T>;
}

See also the meta-tracking issue for const fns, #57563.

Blocked on:

• Tracking issue for &mut T in const contexts (const_mut_refs) #57349
• Tracking Issue for const_replace #83164

Also see the corresponding Result tracking issue: #82814.

[peter-lyons-kehl]

Yes for constantifying Option.expect.

However, as per https://doc.rust-lang.org/nightly/src/core/option.rs.html, Option.expect(self, msg: &str) calls (private) fn expect_failed(msg: &str), which uses panic!("{}", msg). Using panic! with more than one argument is not const-friendly:

    --> library/core/src/macros/mod.rs:18:38
     |
7    | / macro_rules! panic {
8    | |     () => (
9    | |         $crate::panic!("explicit panic")
10   | |     );
...    |
18   | |         $crate::panicking::panic_fmt($crate::format_args!($fmt, $($arg)+))
     | |                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ in this macro invocation (#2)
19   | |     );
20   | | }
     | |_- in this expansion of `panic!` (#1)
...
761  | /     macro_rules! format_args {
762  | |         ($fmt:expr) => {{ /* compiler built-in */ }};
763  | |         ($fmt:expr, $($args:tt)*) => {{ /* compiler built-in */ }};
764  | |     }
     | |_____- in this expansion of `$crate::format_args!` (#2)
     | 
    ::: library/core/src/option.rs:1294:5
     |
1294 |       panic!("{}", msg)
     |       ----------------- in this macro invocation (#1)

Since that is not specific to Option, is there any discussion/plan/tracking issue on making panic const-friendly? Isn't it reasonable to assume that any panic is a panic? Or, can panic fail (for example, if formatting fails) and not panic?

[memoryruins]

@peter-kehl the tracking issue for panicking in constants is #51999

[davidhewitt]

FYI anyone looking at .unwrap_or - I just naively tried to add this, but given that T may impl Drop, this is currently unsupported.

I wonder if it would be feasible for the compiler to allow use of .unwrap_or for types that do impl drop - e.g. only fail when trying to const-evaluate .unwrap_or for T: impl Drop.

[jhpratt]

@davidhewitt Given that neither const trait impls nor const trait bounds are usable on stable, it would be quite unintuitive if this were. Even on nightly, const traits have yet to be RFC accepted.

[davidhewitt]

Sorry, I typo'd above - I meant to say only allow types which don't impl Drop.

We probably wouldn't want this in the function signature (should just be const fn unwrap_or(default: T)). The compiler could be aware that in some paths inside the function default is disposed of, and so reject substitutions during const evaluation for T which impl Drop.

TBH it sounds messy and slightly leaks information about the function implementation, so I'm unconvinced it's worth the effort. Just musing of a way to allow some forms of const unwrap_or before const impl Trait / const Drop is ready.

[jhpratt]

Yeah, I figured it was a typo and responded accordingly.

I still think it would be awkward to have this magically work for some types but not others, especially if this isn't in the function signature. I'd much rather wait for const trait impls to be RFC approved and land on stable, as that would allow way more than just this. Just look at the blockers on #82814 and realize that having const trait impls would allow ~80% of them (just guessing, I haven't bothered to actually calculate a percentage).

[jhpratt]

If/when #51999 is stabilized, Option::expect and Option::unwrap should be unblocked (I haven't checked this, it's just from reading source code).

[CodesInChaos]

@jhpratt Option::expect passes more than one argument to panic! (and the second argument isn't const), so it'll need more work than the minimal version of const panics considered for stabilization at the moment.

[mbartlett21]

replace, take, and copied would also be some more that can be done.

Can @9999years add these to the list at the top?

[RalfJung]

I've cleaned up and updated the list -- some things were listed but they were not even unstably const (such as and, xor, or), others were missing (as_mut, take, replace).

[RalfJung]

@rust-lang/libs-api with #83164 in FCP, I think we can finally stabilize this -- some long-stable fn becoming const fn. Including Option::unwrap which has been requested quite a lot. :)

[dtolnay]

@rfcbot fcp merge

Everything listed in #67441 (comment) (courtesy of Ralf—thank you).

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

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.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[tgross35]

Candidate PR: #131120