show pointer as Rust struct

[web.git] / personal / _posts / 2018-07-19-const.md

diff --git a/personal/_posts/2018-07-19-const.md b/personal/_posts/2018-07-19-const.md
index 2bcd00967f9f58bcaa2f6d3b35fb0ff40c59f828..a2f95525f01afd20a438b5861acefc5717cd4fc8 100644 (file)
--- a/personal/_posts/2018-07-19-const.md
+++ b/personal/_posts/2018-07-19-const.md
@@ -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,7 +33,7 @@ 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.
 
 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.