From fd63fc58408c74c9c643d83307a0ee047054fa73 Mon Sep 17 00:00:00 2001 From: Ralf Jung Date: Mon, 17 Jul 2017 19:06:05 -0700 Subject: [PATCH] clarify 'elements' of a type --- personal/_posts/2017-07-17-types-as-contracts.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/personal/_posts/2017-07-17-types-as-contracts.md b/personal/_posts/2017-07-17-types-as-contracts.md index 8ad613f..125a1aa 100644 --- a/personal/_posts/2017-07-17-types-as-contracts.md +++ b/personal/_posts/2017-07-17-types-as-contracts.md @@ -29,8 +29,8 @@ I'd like to propose that the fundamental reason this is UB is the *type* of the Borrowing some terminology from related fields, we can see the function type as stating a *contract*: The `&mut` say that `simple` expects to be called with non-aliasing pointers. If we violate the contract, all bets are off. -To realize this idea, we need to define, for every type, what is the contract associated with that type. When are elements of any given type *valid*? -For some types, that's simple: `i32` is any four-byte value. `bool` is one byte, either `0` or `1`. +To realize this idea, we need to define, for every type, what is the contract associated with that type. When is some piece of storage *valid* at any given type? +For some types, that's simple: `i32` is any fully initialized four-byte value. `bool` is one byte, either `0` (representing `false`) or `1` (representing `true`). Compound types like `(T, U)` are defined in terms of their constituent types: The first component must be a valid `T`, the second component a valid `U`. Where it gets interesting is the reference types: `&mut T` says that we have a (non-null, properly aligned) pointer. -- 2.30.2