From: Ralf Jung Date: Tue, 18 Jul 2017 02:06:05 +0000 (-0700) Subject: clarify 'elements' of a type X-Git-Url: https://git.ralfj.de/web.git/commitdiff_plain/8f92e31c6d6af083370aaf5760fb856fa55d5728 clarify 'elements' of a type --- 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.