link to compcert

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

diff --git a/ralf/_posts/2018-07-19-const.md b/ralf/_posts/2018-07-19-const.md
index 590763062154d9ead86e1f5afe76acba48c95fcd..2bcd00967f9f58bcaa2f6d3b35fb0ff40c59f828 100644 (file)
--- a/ralf/_posts/2018-07-19-const.md
+++ b/ralf/_posts/2018-07-19-const.md
@@ -39,6 +39,7 @@ Clearly, we don't want CTFE to have actually observable side-effects outside of
 
 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.*
 
@@ -138,7 +139,8 @@ So, we will likely have to live with either considering floating point operation
 I think it is possible to achieve CTFE correctness for all other operations, and I think we should strive to do so.
 
 Before we go on, notice that CTFE correctness as defined above does not say anything about the case where CTFE fails with an error, e.g. because of an unsupported operation.
-That is a deliberate choice because it lets us gradually improve the operations supported by CTFE, but it is a choice that not everyone might agree with.
+CTFE would be trivially correct (in the above sense) if it just always immediately returned an error.
+However, since const-safe programs cannot error during CTFE, we know from CTFE correctness that *those* programs *do* in fact behave exactly the same at compile-time and at run-time.
 
 ## Unsafe Blocks in Const Context