Tracking Issue for the use of `?` in constants

[oli-obk]

The ? operator expands to invoking Try::into_result for the argument and Into::into for the error of the result. In order to support these, we need to

• Figure out traits-in-const: Tracking Issue for removing impl const and ~const in the standard library #110395
• stabilize impl const Trait for Type items Tracking Issue for RFC 3762, "Make trait methods callable in const contexts" #143874
• implement const Try for Result and Option in libstd Constify Try, From, TryFrom and relevant traits #143768

[a1phyr]

#60964 also needs to be resolved to be able to implement const Try.
See https://play.rust-lang.org/?version=nightly&gist=bdf8f8e2774f54c084e2cb25624ce193

[jhpratt]

Would it be reasonable to permit ? in const fn only for Option<T> for now? The only thing would have to change is the desugaring, I think.

[oli-obk]

You mean to make the desugaring different if we're in a const fn?

[jhpratt]

I don't see any reason we couldn't desugar to this unconditionally for Option<T>:

match opt {
    Some(val) => val,
    None => return None,
}

Sure, the Try trait was designed with this in mind, but ultimately it is just a matter of desugaring the syntax. There's no semantic difference. Result<T, E> is more complicated due to the E::from(err) call, which can't be stable const fn right now anyways.

If it's possible to stabilize it on Option<T> without changing the desugar, that would be great. But I don't think it is possible until we stabilize both Try and const_trait_impl, which seems a ways off still.

Plus, who knows. There might be a small performance benefit to changing the desugaring to something simpler.

[oli-obk]

The reason we can't do this is that during desugaring we don't know what the type is. We compute types after desugaring.

[jhpratt]

Ah, dang. For some reason I thought the order was the other way around.