@@ -147,23 +147,26 @@ Choose an argument type that rules out bad inputs.
147147For example, prefer
148148
149149```rust
150- fn foo(a: ascii::Ascii) { ... }
150+ enum FooMode {
151+ Mode1,
152+ Mode2,
153+ Mode3,
154+ }
155+ fn foo(mode: FooMode) { ... }
151156```
152157
153158over
154159
155160```rust
156- fn foo(a: u8) { ... }
161+ fn foo(mode2: bool, mode3: bool) {
162+ assert!(!mode2 || !mode3);
163+ ...
164+ }
157165```
158166
159- Note that `ascii::Ascii`
160- is a _wrapper_ around `u8` that guarantees the highest bit is zero; see
161- [newtype patterns](../types/newtype.md) for more details on creating typesafe wrappers.
162-
163167Static enforcement usually comes at little run-time cost: it pushes the
164- costs to the boundaries (e.g. when a `u8` is first converted into an
165- `Ascii`). It also catches bugs early, during compilation, rather than through
166- run-time failures.
168+ costs to the boundaries. It also catches bugs early, during compilation,
169+ rather than through run-time failures.
167170
168171On the other hand, some properties are difficult or impossible to
169172express using types.
@@ -176,7 +179,7 @@ downsides:
176179
1771801. Runtime overhead (unless checking can be done as part of processing the input).
1781812. Delayed detection of bugs.
179- 3. Introduces failure cases, either via `fail !` or `Result`/`Option` types (see
182+ 3. Introduces failure cases, either via `panic !` or `Result`/`Option` types (see
180183 the [error handling guidelines](../../errors/README.md)), which must then be
181184 dealt with by client code.
182185
0 commit comments