clarify extra-hidden-state-in-memory
[web.git] / ralf / _posts / 2018-07-19-const.md
index 23e9325ba43555e8b20de0e12f2b0f7783887fc7..a2f95525f01afd20a438b5861acefc5717cd4fc8 100644 (file)
@@ -16,7 +16,7 @@ Expect something like a structured brain dump, so there are some unanswered ques
 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.
 
 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.
+Notice that CTFE is *not* the same as constant propagation: Constant propagation is an optimization pass done by compilers like LLVM that will opportunistically change code like `3 + 4` into `7` to avoid run-time work.
 Being an optimization, constant propagation must, by definition, not change program behavior and will not be observable at all (other than performance).
 CTFE, on the other hand, is about code that *must* be executed at compile-time because the compiler needs to know its result to proceed -- for example, it needs to know the size of an array to compute how to lay out data in memory.
 You can statically see, just from the syntax of the code, whether CTFE applies to some piece of code or not:
 Being an optimization, constant propagation must, by definition, not change program behavior and will not be observable at all (other than performance).
 CTFE, on the other hand, is about code that *must* be executed at compile-time because the compiler needs to know its result to proceed -- for example, it needs to know the size of an array to compute how to lay out data in memory.
 You can statically see, just from the syntax of the code, whether CTFE applies to some piece of code or not:
@@ -33,12 +33,13 @@ We say that the `3 + 4` above is in *const context* and hence subject to CTFE, b
 
 Not all operations can be used in const context.
 For example, it makes no sense to compute your array length as "please go read that file from disk and compute something" -- we can't know what will be on the disk when the program actually runs.
 
 Not all operations can be used in const context.
 For example, it makes no sense to compute your array length as "please go read that file from disk and compute something" -- we can't know what will be on the disk when the program actually runs.
-We could use the disk of the machine compiling the program, but that does not sound very appearling either.
+We could use the disk of the machine compiling the program, but that does not sound very appealing either.
 Things get even worse when you consider letting the program send information to the network.
 Clearly, we don't want CTFE to have actually observable side-effects outside of compilation.
 
 In fact, just naively letting programs read files would also be grossly unsafe:
 When computing the length of an array twice, it is important that we obtain the same result.
 Things get even worse when you consider letting the program send information to the network.
 Clearly, we don't want CTFE to have actually observable side-effects outside of compilation.
 
 In fact, just naively letting programs read files would also be grossly unsafe:
 When computing the length of an array twice, it is important that we obtain the same result.
+**Update:** As @eddyb points out, things get even worse once you consider const generics, traits, and coherence: At that point, you have to [rely on evaluating the same expression in different crates to produce the same result](https://internals.rust-lang.org/t/mir-constant-evaluation/3143/47). **/Update**
 
 > *CTFE must be deterministic.*
 
 
 > *CTFE must be deterministic.*