Tracking Issue for const_eval_select

[RalfJung]

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 add float semantics RFC rfcs#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: What are the guarantees around which constants (and callees) in a function get monomorphized? #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

• Write an RFC
• Implement the RFC
• Adjust documentation (see instructions on rustc-dev-guide)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

XXX --- list all the "unresolved questions" found in the RFC to ensure they are
not forgotten

Implementation history

Related issues

• Must a const fn behave exactly the same at runtime as at compile-time? #77745

[RalfJung]

Cc @rust-lang/wg-const-eval

[coolreader18]

For syntax - I could imagine a macro in core that expands to builtin#is_const_eval, and then the const checker special-cases an if with that as the condition. Perhaps that's too magic, but I feel like the macro would communicate that there's something special going on.

if core::is_const_eval!() {
    // ...
} else {
    // ...
}

[RalfJung]

I don't think a macro is enough. Note that if you change the code like this, it will no longer have the right behavior:

let b = core::is_const_eval!();
if b {
    // ...
} else {
    // ...
}

So, we'd want the macro to error when it is not used as the sole condition of an if. (if core::is_const_eval!() && other also cannot work.)

[nvzqz]

Rather than go with a macro, we could have the language make use of the existing keyword by simply having if const {.

[jhpratt]

I feel like there's a situation where that wouldn't work due to the existence of inline const, but can't come up with a simple example off-hand.

[oli-obk]

I feel like there's a situation where that wouldn't work due to the existence of inline const, but can't come up with a simple example off-hand.

if const { } { } parses as if (const {}) {} and then fails typeck. if const {} just fails parsing. Also it's just too confusing imo to have two syntactical constructs so close to each other, even if we can get away with it.

if in const {} has been proposed before

[AtomicGamer9523]

I feel like it can be passed as part of the cfg macro, so that it could be used in a cfg_if! situation.

cfg_if! {
    if #[cfg(const_eval)] {
        // Constant
    } else {
        // Non-constant
    }
}