Tracking issue for const Option functions

[9999years]

Current candidates with feature = const_option include

• is_some, is_none
• as_ref
• expect
• unwrap_or, unwrap_or_else Requires Calling methods on generic parameters of const fns rfcs#2632 to use functional interfaces (in specific, trait bounds on generic fns).
• ok_or, ok_or_else
• and, and_then
• filter
• or, or_else
• xor
• transpose
• flatten

See also the meta-tracking issue for const fns, #57563.
Working on this in PR #66884.

Blocked on #73255.

[peter-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?

[lilasta]

Option::as_mut has been constified: #89953

[CodesInChaos]

Since the panic now seems to support non-const strings as second argument, Option::expect can now be stabilized, right?

[jhpratt]

@CodesInChaos I believe it's blocked on const_precise_live_drops, along with a number of other methods.

[lilasta]

Option::expect has been constified: #90269

[jhpratt]

unstably for those not looking in further detail ^^

[clarfonthey]

Was there any actual blocker to stabilising Option::unwrap and Option::expect? It's been over a year and I could have sworn they were already stabilised, but I guess not.

[jhpratt]

Precise live drops (or whatever it's called) is the sole blocker to my knowledge.

[c410-f3r]

AFAICT, little progress were made since #73255 (comment) so I guess stabilization is likely going to take some time.