Skip to content

Tracking Issue for the use of ? in constants #74935

New issue

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

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

Already on GitHub? # to your account

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, covers all const contexts (static, const fn, ...) C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC

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: An issue tracking the progress of sth. like the implementation of an RFC label Jul 30, 2020
@jonas-schievink jonas-schievink added the A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) 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.

apoelstra added a commit to rust-bitcoin/rust-bitcoin that referenced this issue Nov 13, 2024
1db4b72 Mark function as const (yancy)

Pull request description:

  We discussed marking from_vb as const here: #3602

  However, from what I can tell, map() isn't const and I don't see a tracking issue for changing it.  Also, the question mark operator isn't available in const context either, although there is a tracking issue for that: rust-lang/rust#74935.  It will be a long while before that makes it into this projects MSRV if/when it lands.

  There are some other functions in this module that could use the same re-write to make them const as well it looks like.

ACKs for top commit:
  tcharding:
    ACK 1db4b72
  apoelstra:
    ACK 1db4b72; successfully ran local tests

Tree-SHA512: 62b612791dd3ce2f6ebf27f586a1262633a46566b9fd3583984171f62209714ad979439345fe86d8ef87d2f78a2cee21d619e2eb3621689faf59d81640e9f77c
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC
Projects
None yet
Development

No branches or pull requests

4 participants