Repository: rust
Issue: Tracking Issue for const_eval_select
Labels: T-lang,C-tracking-issue,A-const-eval

<!--
NOTE: For library features, please use the "Library Tracking Issue" template instead.

Thank you for creating a tracking issue! 📜 Tracking issues are for tracking a
feature from implementation to stabilisation. Make sure to include the relevant
RFC for the feature if it has one. Otherwise provide a short summary of the
feature and link any relevant PRs or issues, and remove any sections that are
not relevant to the feature.

Remember to add team labels to the tracking issue.
For a language team feature, this would e.g., be `T-lang`.
Such a feature should also be labeled with e.g., `F-my_feature`.
This label is used to associate issues (e.g., bugs and design questions) to the feature.
-->

This is a tracking issue for the const_eval_select intrinsic.

The intrinsic provides a way for a `const fn` to check whether it runs at compile time or at runtime. Several major points need to be resolved before it can be stabilized:

- Do we even want to allow `const fn` to do something like this? Or do we want to guarantee the property that `const fn` behave the same at runtime and at compile time? Currently they behave the same.

  Even if https://github.com/rust-lang/rfcs/pull/3514 gets accepted, the set of possible return values of a function is the same at compile time and at runtime (but the actual concrete return value that is chosen may differ).   const_eval_select is qualitatively different from allowing float operations in `const fn`. With floats, the compile time behavior can actually be seen at runtime if optimizations kick in -- and while it is possible to do horrible things with black_box to write a function that de facto is always  `true` at compile time and `false` at runtime on x86, (a) this is clearly cursed, and (b) it's actually not possible to do this in a portable way.

  Note that one could specify const_eval_select as "at runtime, non-deterministically pick either the compile time or the runtime behavior (but implementations generally will prefer the runtime behavior)". That would formally satisfy the requirement that every compile-time behavior is also possible at runtime (but the opposite direction would cease to hold when const_eval_select becomes stable). However this is a silly way to achieve that property -- de facto, it becomes possible to write a function that is always `true` at compile time and `false` at runtime, and the mere fact that it may return `true` at runtime (but actually it never does) will not stop people from relying on it. I call this "gratuitous non-determinism" -- this is non-determinism that doesn't actually occur in practice and exists solely to satisfy some abstract property of the spec. I think the `align_offset` story showed us that gratuitous non-determinism is very confusing and it is hard to prevent people from just ignoring it.

- Assuming we want something like const_eval_select, how should it be exposed on stable? The problem is that a `fn is_const_eval() -> bool` is insufficient, because if you do `if is_const_eval() { ... } else { ... }`, the const-checker will still require both arms to only call `const fn`. That's why const_eval_select has this awkward interface where you give it two functions and it calls one of them. But the interface is truly awkward and ideally we can find something better.

    I think there is possible overlap here with the discussions around `const if` and controlling which constants and called functions get monomorphized: https://github.com/rust-lang/rust/issues/122301. If `const if EXPR` already says that only the arm actually taken will be monomorphized, then maybe `const if is_const_eval()` only const-checks one of the arms? That would still be a very special magic case though since we can't evaluate the conditional to a bool first. Wrapping `is_const_eval` in your own function would change its behavior. This really feels like it has to be primitive syntax, but I don't know what the syntax should be.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

### Steps
<!--
Include each step required to complete the feature. Typically this is a PR
implementing a feature, followed by a PR that stabilises the feature. However
for larger features an implementation could be broken up into multiple PRs.
-->

- [ ] Write an RFC
- [ ] Implement the RFC
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Formatting for new syntax has been added to the [Style Guide] ([nightly-style-procedure])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs
[nightly-style-procedure]: https://github.com/rust-lang/style-team/blob/master/nightly-style-procedure.md 
[Style Guide]: https://github.com/rust-lang/rust/tree/master/src/doc/style-guide

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

XXX --- list all the "unresolved questions" found in the RFC to ensure they are
not forgotten

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->

### Related issues

- https://github.com/rust-lang/rust/issues/77745