Decide on guarantees for evaluation of associated consts and const blocks about rust

[CAD97]

Theoretically a const if could be specified to do something stronger than making the untaken branch "dead code" and thus get behavior more like if the branch is outlined in a separate function and thus (potentially) never monomorphized. The language that C++'s constexpr if uses is roughly that the statement is discarded without ever being instantiated. The difference between "if expression where the condition is evaluated at const time" and "conditional compilation selection of expression blocks controlled by const time evaluation" is why I typically discuss the relevant feature as "static if" rather than as "const if".

However, it is still the case that "syntactically mentioned" is determined before any const evaluation is done by any reasonable interpretation. #[cfg] and macro expansion get intertwined with syntax, but const is definitively after. At least while type associated syntax macros continue to not exist.

I'd personally be quite happy to see a written guarantee that if a const expression is "evaluated" at runtime then that requires that the backing const item must have been evaluated at compile time regardless of what is (or isn't) done with the result of that evaluation at runtime. It's both an obvious rule and entirely independent of any details of the compilation model.

What I'd prefer not to see (yet) is any (new) guarantees of when const items are guaranteed to not be evaluated. While I concede to reality, I still strongly prefer consts being more eagerly required to be well-formed.

[RalfJung]

I'd personally be quite happy to see a written guarantee that if a const expression is "evaluated" at runtime then that requires that the backing const item must have been evaluated at compile time regardless of what is (or isn't) done with the result of that evaluation at runtime. It's both an obvious rule and entirely independent of any details of the compilation model.

Yeah that was my thinking as well, which is why proposed exactly that.

What I'd prefer not to see (yet) is any (new) guarantees of when const items are guaranteed to not be evaluated. While I concede to reality, I still strongly prefer consts being more eagerly required to be well-formed.

Agreed as well, which is why my proposal does not make any such guarantees.

[joshlf]

This should be enough for our needs. Thanks for your work on this!

cc @jswrenn

[ChayimFriedman2]

I don't understand: isn't the entire purpose of const if that even though constants in dead code are evaluated, this branch won't be evaluated if not taken?

[RalfJung]

Those two statements are in contradiction, aren't they?

const if false {
  const { panic!(); } // this is in dead code
}

So we can't just say "const in dead code are evaluated". We have to say "const in dead code are evaluated, except ...". It's not okay to make a blanket statement and then restrict it elsewhere -- that makes the blanket statement just false.

[traviscross]

@rustbot labels -I-lang-nominated

We discussed this today in lang triage. People agreed that this is a reasonable and minimal first step, and rust-lang/reference#1497 is now in FCP.