X-Git-Url: https://git.ralfj.de/web.git/blobdiff_plain/d3f8f5950feeeba2aed2f9d7cc32238e0045995f..6a2d50f8dca45eed07950f1814a9c1f91056dc82:/personal/_posts/2017-08-11-types-as-contracts-evaluation.md

diff --git a/personal/_posts/2017-08-11-types-as-contracts-evaluation.md b/personal/_posts/2017-08-11-types-as-contracts-evaluation.md
index e06ccc0..226d48f 100644
--- a/personal/_posts/2017-08-11-types-as-contracts-evaluation.md
+++ b/personal/_posts/2017-08-11-types-as-contracts-evaluation.md
@@ -1,6 +1,7 @@
 ---
 title: "Types as Contracts: Implementation and Evaluation"
 categories: internship rust
+forum: https://internals.rust-lang.org/t/https-www-ralfj-de-blog-2017-08-11-types-as-contracts-evaluation-html/5753
 ---
 
 Some weeks ago, I described [Types as Contracts]({{ site.baseurl }}{% post_url 2017-07-17-types-as-contracts %}) as an approach for how to go about defining Rust's aliasing-related [undefined behavior]({{ site.baseurl }}{% post_url 2017-07-14-undefined-behavior %}).
@@ -77,7 +78,7 @@ However, it turns out that `mem::uninitialized` is causing other problems as wel
 
 This is the most interesting case I found.  The `Arc` destructor ends up calling `Arc::drop_slow`, which is implemented as follows:
 {% highlight rust %}
- unsafe fn drop_slow(&mut self) {
+unsafe fn drop_slow(&mut self) {
     let ptr = self.ptr.as_ptr();
 
     // Destroy the data at this time, even though we may not free the box