Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for the use of ? in constants #74935

Open
oli-obk opened this issue Jul 30, 2020 · 6 comments
Open

Tracking Issue for the use of ? in constants #74935

oli-obk opened this issue Jul 30, 2020 · 6 comments
Labels
A-const-eval Area: Constant evaluation (MIR interpretation) C-tracking-issue Category: A tracking issue for an RFC or an unstable feature.

Comments

@oli-obk
Copy link
Contributor

oli-obk commented Jul 30, 2020

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

@oli-obk oli-obk added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jul 30, 2020
@jonas-schievink jonas-schievink added the A-const-eval Area: Constant evaluation (MIR interpretation) label Jul 30, 2020
@a1phyr
Copy link
Contributor

a1phyr commented Jul 30, 2020

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

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 30, 2021
Constify ?-operator for Result and Option

Try to make `?`-operator usable in `const fn` with `Result` and `Option`, see rust-lang#74935 . Note that the try-operator itself was constified in rust-lang#87237.

TODO
* [x] Add tests for const T -> T conversions
* [x] cleanup commits
* [x] Remove `#![allow(incomplete_features)]`
* [?] Await decision in rust-lang#86808 - I'm not sure
* [x] Await support for parsing `~const` in bootstrapping compiler
* [x] Tracking issue(s)? - rust-lang#88674
@jhpratt
Copy link
Member

jhpratt commented Mar 1, 2022

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
Copy link
Contributor Author

oli-obk commented Mar 1, 2022

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

@jhpratt
Copy link
Member

jhpratt commented Mar 1, 2022

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
Copy link
Contributor Author

oli-obk commented Mar 1, 2022

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
Copy link
Member

jhpratt commented Mar 1, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation (MIR interpretation) C-tracking-issue Category: A tracking issue for an RFC or an unstable feature.
Projects
None yet
Development

No branches or pull requests

4 participants