---

yaml
---
r: 236021
b: refs/heads/stable
c: fabbd4e
h: refs/heads/master
i:
  236019: 8e27be8
v: v3

Author: Gankra

[refs]

@@ -29,7 +29,7 @@ refs/heads/tmp: afae2ff723393b3ab4ccffef6ac7c6d1809e2da0
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: f859507de8c410b648d934d8f5ec1c52daac971d
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828
-refs/heads/stable: c3c9d9140530a9709449fd32e830bf88f567845c
+refs/heads/stable: fabbd4e8630ca1087fb69dca978ab7916d2d1adf
 refs/tags/1.0.0: 55bd4f8ff2b323f317ae89e254ce87162d52a375
 refs/tags/1.1.0: bc3c16f09287e5545c1d3f76b7abd54f2eca868b
 refs/tags/1.2.0: f557861f822c34f07270347b94b5280de20a597e

branches/stable/lifetimes.md

@@ -474,16 +474,9 @@ struct Foo<'a, 'b, A, B, C, D, E, F, G, H> {
 
 
 
-
-## Dropck
-
-TODO
-
-
 ## PhantomData
 
-
-However when working with unsafe code, we can often end up in a situation where
+When working with unsafe code, we can often end up in a situation where
 types or lifetimes are logically associated with a struct, but not actually
 part of a field. This most commonly occurs with lifetimes. For instance, the `Iter`
 for `&'a [T]` is (approximately) defined as follows:
@@ -498,7 +491,8 @@ pub struct Iter<'a, T: 'a> {
 However because `'a` is unused within the struct's body, it's *unbound*.
 Because of the troubles this has historically caused, unbound lifetimes and
 types are *illegal* in struct definitions. Therefore we must somehow refer
-to these types in the body.
+to these types in the body. Correctly doing this is necessary to have
+correct variance and drop checking.
 
 We do this using *PhantomData*, which is a special marker type. PhantomData
 consumes no space, but simulates a field of the given type for the purpose of
@@ -516,8 +510,50 @@ pub struct Iter<'a, T: 'a> {
 }
 ```
 
-However PhantomData is also necessary to signal important information to
-*dropck*. (TODO)
+
+
+
+## Dropck
+
+When a type is going out of scope, Rust will try to Drop it. Drop executes
+arbitrary code, and in fact allows us to "smuggle" arbitrary code execution
+into many places. As such additional soundness checks (dropck) are necessary to
+ensure that a type T can be safely instantiated and dropped. It turns out that we
+*really* don't need to care about dropck in practice, as it often "just works".
+
+However the one exception is with PhantomData. Given a struct like Vec:
+
+```
+struct Vec<T> {
+    data: *const T, // *const for covariance!
+    len: usize,
+    cap: usize,
+}
+```
+
+dropck will generously determine that Vec<T> does not contain any values of
+type T. This will unfortunately allow people to construct unsound Drop
+implementations that access data that has already been dropped. In order to
+tell dropck that we *do* own values of type T and may call destructors of that
+type, we must add extra PhantomData:
+
+```
+struct Vec<T> {
+    data: *const T, // *const for covariance!
+    len: usize,
+    cap: usize,
+    _marker: marker::PhantomData<T>,
+}
+```
+
+Raw pointers that own an allocation is such a pervasive pattern that the
+standard library made a utility for itself called `Unique<T>` which:
+
+* wraps a `*const T`,
+* includes a PhantomData<T>,
+* auto-derives Send/Sync as if T was contained
+* marks the pointer as NonZero for the null-pointer optimization
+