@ -1533,6 +1533,10 @@ Once language support becomes available (e.g., see the [contract proposal](http:
`Expects()` can also be used to check a condition in the middle of an algorithm.
##### Note
No, using `unsigned` is not a good way to sidestep the problem of [ensuring that a value is nonnegative](#Res-nonnegative).
##### Enforcement
(Not enforceable) Finding the variety of ways preconditions can be asserted is not feasible. Warning about those that can be easily identified (`assert()`) has questionable value in the absence of a language facility.
@ -9310,6 +9314,8 @@ Arithmetic rules:
* [ES.103: Don't overflow](#Res-overflow)
* [ES.104: Don't underflow](#Res-underflow)
* [ES.105: Don't divide by zero](#Res-zero)
* [ES.106: Don't try t avoid negative values by using `unsigned`](#Res-nonnegative)
* [ES.107: Don't use `unsigned` for subscripts](#Res-subscripts)
### <aname="Res-lib"></a>ES.1: Prefer the standard library to other libraries and to "handcrafted code"
@ -11875,6 +11881,122 @@ This also applies to `%`.
* Flag division by an integral value that could be zero
### <aname="Res-nonnegative"></a>ES.106: Don't try to avoid negative values by using `unsigned`
##### Reason
Choosing `unsigned` implies many changes to the usual behavior of integers, including modulo arithmetic,
can suppress warnings related to overflow,
and opens the door for errors related to signed/unsigned mixes.
Using `unsigned` doesn't actually eliminate the possibility of negative values.
##### Example
unsigned int u1 = -2; // OK: the value of u1 is 4294967294
int i1 = -2;
unsigned int u2 = i1; // OK: the value of u2 is -2
int i2 = u2; // OK: the value of i2 is -2
These problems with such (perfectly legal) constructs are hard to spot in real code and are the source of many real-world errors.