From d4d1b2f0ebe6d8f2684ca1c9ec6fe0dc27c62feb Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Sun, 4 Feb 2018 10:22:03 +0100 Subject: [PATCH] fix subtyping typo --- ralf/_posts/2018-01-31-sharing-for-a-lifetime.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ralf/_posts/2018-01-31-sharing-for-a-lifetime.md b/ralf/_posts/2018-01-31-sharing-for-a-lifetime.md index 8dd10da..0b7a454 100644 --- a/ralf/_posts/2018-01-31-sharing-for-a-lifetime.md +++ b/ralf/_posts/2018-01-31-sharing-for-a-lifetime.md @@ -135,7 +135,7 @@ This is not so say that the last word on interior mutability has been spoken; th Either way, this model has certainly helped me not only in the formal work on RustBelt, but also in thinking about the Rust type system itself. For example, I briefly wondered why `Cell` is not covariant. -Indeed, if `U <: T`, then it is perfectly safe to turn a `Cell` into a `Cell` -- that is to say, whenever some sequence of bytes is valid at `Cell`, it is also valid at `Cell`. +Indeed, if `T <: U`, then it is perfectly safe to turn a `Cell` into a `Cell` -- that is to say, whenever some sequence of bytes is valid at `Cell`, it is also valid at `Cell`. (In fact, the owned invariant for `Cell` is *exactly the same* as the one for `T`!) That's precisely what we need for covariance, right? Well, not exactly -- because our types have two invariants, we also have to require that whenever a pointer is a shared `Cell`, it is a shared `Cell`, and that is decisively *not* true! -- 2.30.2