---
title: "Thoughts on Compile-Time Function Evaluation and Type Systems"
categories: internship rust
+forum: https://internals.rust-lang.org/t/thoughts-on-compile-time-function-evaluation-and-type-systems/8004
---
For some time now (since the 1.26 release, to be precise), Rust has a [very powerful machinery for CTFE](https://github.com/rust-lang/rust/pull/46882), or compile-time function evaluation.
-Since then, there have been various discussions about which operations should be allowed during CTFE, which checks the compiler should do, and which kinds of guarantees we should be able to expect around CTFE.
-This post is my take on those topics, and it should not be surprising that I am going to take a very type-system centric view. :)
+Since then, there have been various discussions about which operations should be allowed during CTFE, which checks the compiler should do, how this all relates to promotion and which kinds of guarantees we should be able to expect around CTFE.
+This post is my take on those topics, and it should not be surprising that I am going to take a very type-system centric view.
Expect something like a structured brain dump, so there are some unanswered questions towards the end as well.
<!-- MORE -->
## 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 :)
-Thanks to @oli-obk for feedback on a draft of this post.
-<!-- If you have feedback or questions, [let's discuss in the internals forum]()! -->
+Thanks to @oli-obk for feedback on a draft of this post, and to @centril for interesting discussion in #rust-lang that triggered me into developing these ideas and terminology.
+If you have feedback or questions, [let's discuss in the internals forum](https://internals.rust-lang.org/t/thoughts-on-compile-time-function-evaluation-and-type-systems/8004)!
projects / web.git / blobdiff