---

yaml
---
r: 228994
b: refs/heads/try
c: 35b8001
h: refs/heads/master
v: v3

Author: Gankra

[refs]

@@ -1,7 +1,7 @@
 ---
 refs/heads/master: aca2057ed5fb7af3f8905b2bc01f72fa001c35c8
 refs/heads/snap-stage3: 1af31d4974e33027a68126fa5a5a3c2c6491824f
-refs/heads/try: 5ec12b154bcc839f9a903f238791b6010a61418b
+refs/heads/try: 35b8001f684399992978c60fcb3d51232b3ca85d
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try/subtyping.md

@@ -48,11 +48,11 @@ interactions with other features.)
 Some important variances:
 
 * `&` is variant (as is `*const` by metaphor)
-* `&mut` is invariant (as is `*mut` by metaphor)
+* `&mut` is invariant
 * `Fn(T) -> U` is invariant with respect to `T`, but variant with respect to `U`
 * `Box`, `Vec`, and all other collections are variant
 * `UnsafeCell`, `Cell`, `RefCell`, `Mutex` and all "interior mutability"
-  types are invariant
+  types are invariant (as is `*mut` by metaphor)
 
 To understand why these variances are correct and desirable, we will consider several
 examples. We have already covered why `&` should be variant when introducing subtyping:
@@ -158,7 +158,7 @@ in its place. Therefore functions *are* variant over their return type.
 
 `*const` has the exact same semantics as `&`, so variance follows. `*mut` on the
 other hand can dereference to an &mut whether shared or not, so it is marked
-as invariant in analogy to cells.
+as invariant just like cells.
 
 This is all well and good for the types the standard library provides, but
 how is variance determined for type that *you* define? A struct, informally