Skip to content

Commit ee355ae

Browse files
Apply suggestions from code review
Co-authored-by: Dmitri Gribenko <[email protected]>
1 parent 66b4705 commit ee355ae

File tree

1 file changed

+4
-2
lines changed

1 file changed

+4
-2
lines changed

src/idiomatic/leveraging-the-type-system/newtype-pattern/parse-don-t-validate.md

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -48,13 +48,15 @@ impl Username {
4848
can't modify it.
4949

5050
- Stress the importance of evaluating _the entire API surface_ exposed by a
51-
newtype to determine if invariants are indeed bullet-proof.\
51+
newtype to determine if invariants are indeed bullet-proof.
52+
5253
It is crucial to consider all possible interactions, including trait
5354
implementations, that may allow users to bypass the invariants. For example,
5455
if the `Username` type implements the `DerefMut` trait, users can modify the
5556
underlying string directly, bypassing the validation checks in `new`.
5657

57-
- Type-level invariants have second-order benefits.\
58+
- Type-level invariants have second-order benefits.
59+
5860
The input is validated once, at the boundary, and the rest of the program can
5961
rely on the invariants being upheld. We can avoid redundant validation and
6062
"defensive programming" checks throughout the program, reducing noise and

0 commit comments

Comments
 (0)