link to forum

diff --git a/ralf/_posts/2018-07-19-const.md b/ralf/_posts/2018-07-19-const.md
index ee1eab36a853ad3612d9b1c77c4e7bf78299ed98..d523935c8030bcb6ea4e55a1a6f6e795be0a76d2 100644 (file)
--- a/ralf/_posts/2018-07-19-const.md
+++ b/ralf/_posts/2018-07-19-const.md
@@ -1,11 +1,12 @@
 ---
 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 -->
@@ -231,4 +232,4 @@ There are still plenty of open questions, in particular around the interaction o
 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]()! -->
+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)!