## Some Background
-CTFE is the mechanism used by the compiler, primarily, to evaluate items like `const x : T = ...;`.
+CTFE is the mechanism used by the compiler, primarily, to evaluate items like `const x: T = ...;`.
The `...` here is going to be Rust code that must be "run" at compile-time, because it can be used as a constant in the code -- for example, it can be used for array lengths.
Notice that CTFE is *not* the same as constant propagation: Constant propagation is an optimization pass done by LLVM that will opportunistically change code like `3 + 4` into `7` to avoid run-time work.
CTFE is only used in places like the value of a `const` or the length of an array.
{% highlight rust %}
fn demo() {
- const X : u32 = 3 + 4; // CTFE
- let x : u32 = 4 + 3; // no CTFE (but maybe constant propagation)
+ const X: u32 = 3 + 4; // CTFE
+ let x: u32 = 4 + 3; // no CTFE (but maybe constant propagation)
}
{% endhighlight %}
We say that the `3 + 4` above is in *const context* and hence subject to CTFE, but the `4 + 3` is not.
## Conclusion
I have discussed the notions of CTFE determinism and CTFE correctness (which are properties of a CTFE engine like miri), as well as const safety (property of a piece of code) and const soundness (property of a type system).
+In particular, I propose that *when type-checking safe code in const context, we guarantee that this code is const-safe*, i.e., that it will not hit a CTFE error (though panics are allowed, just like they are in "run-time" Rust code).
+
There are still plenty of open questions, in particular around the interaction of [`const fn` and traits](https://github.com/rust-lang/rust/issues/24111#issuecomment-311029471), but I hope this terminology is useful when having those discussions.
Let the type systems guide us :)