@@ -147,23 +147,26 @@ Choose an argument type that rules out bad inputs.
147
147
For example, prefer
148
148
149
149
```rust
150
- fn foo(a: ascii::Ascii) { ... }
150
+ enum FooMode {
151
+ Mode1,
152
+ Mode2,
153
+ Mode3,
154
+ }
155
+ fn foo(mode: FooMode) { ... }
151
156
```
152
157
153
158
over
154
159
155
160
```rust
156
- fn foo(a: u8) { ... }
161
+ fn foo(mode2: bool, mode3: bool) {
162
+ assert!(!mode2 || !mode3);
163
+ ...
164
+ }
157
165
```
158
166
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
-
163
167
Static 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.
167
170
168
171
On the other hand, some properties are difficult or impossible to
169
172
express using types.
@@ -176,7 +179,7 @@ downsides:
176
179
177
180
1. Runtime overhead (unless checking can be done as part of processing the input).
178
181
2. 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
180
183
the [error handling guidelines](../../errors/README.md)), which must then be
181
184
dealt with by client code.
182
185
0 commit comments