clairification

Author: RalfJung

src/items/unions.md

@@ -40,10 +40,12 @@ let f = u.f1;
 Unions have no notion of an "active field".  Instead, every union access just
 interprets the storage at the type of the field used for the access.  Reading a
 union field is equivalent to a [`transmute`]: The data in the union, no matter
-how it was stored there, is transmuted to the type of the field.  Reading data
-at a bad type results in undefined behavior (for example, reading the value `3`
-at type `bool`).  For this reason, all reads of union fields have to be placed
-in `unsafe` blocks:
+how it was stored there, is transmuted to the type of the field.  Just like with
+any other transmute, it is the programmer's responsibility to make sure that the
+data is valid for the field type.  Failing to do so results in undefined
+behavior (for example, reading the value `3` at type `bool` is undefined
+behavior).  For this reason, all reads of union fields have to be placed in
+`unsafe` blocks:
 
 ```rust
 # union MyUnion { f1: u32, f2: f32 }

src/types/union.md

@@ -3,10 +3,10 @@
 A *union type* is a nominal, heterogeneous C-like union, denoted by the name of
 a [`union` item].
 
-A union contains the value of any one of its fields. Since the accessing the
-wrong field can cause unexpected or undefined behaviour, `unsafe` is required
-to read from a union field or to write to a field that doesn't implement
-[`Copy`].
+A union access transmutes the content of the union to the type of the accessed
+field. Since transmutes can cause unexpected or undefined behaviour, `unsafe` is
+required to read from a union field or to write to a field that doesn't
+implement [`Copy`].
 
 The memory layout of a `union` is undefined by default, but the `#[repr(...)]`
 attribute can be used to fix a layout.