From 4ab563b44744ec7083cd724a7131a11ad76efd24 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Thu, 23 Jul 2020 10:43:30 +0200 Subject: [PATCH] fix typo (thanks to Lonami) --- personal/_posts/2018-08-22-two-kinds-of-invariants.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/personal/_posts/2018-08-22-two-kinds-of-invariants.md b/personal/_posts/2018-08-22-two-kinds-of-invariants.md index 34f33bb..fcf12ea 100644 --- a/personal/_posts/2018-08-22-two-kinds-of-invariants.md +++ b/personal/_posts/2018-08-22-two-kinds-of-invariants.md @@ -72,7 +72,7 @@ For `Vec` to work, however, `ptr` will be pointing to valid memory of size `cap This is an invariant that all the unsafe code implementing `Vec` maintains, and it is the invariant that the safe API surface of `Vec` expects the outside world to uphold. The reason this works is that the fields mentioned in this invariant are all private, so safe code cannot break the invariant and use that broken invariant to cause havoc. Again, the safety invariant is about ensuring safe execution of safe code. -Unsafe code can of course break this invariant, but then it us just Doing It Wrong (TM). +Unsafe code can of course break this invariant, but then it is just Doing It Wrong (TM). Thanks to privacy and an abstraction barrier, types in Rust can define *their own safety invariant*, and they can then expect the outside world to respect that invariant. As we have seen with `Vec`, when generic types are involved, these custom safety invariants will often have a "structural" element in that being safe at `Vec` is defined in terms of being safe at `T`. -- 2.30.2