From ee355aebd96a0326904a7c2eb0032554092a1133 Mon Sep 17 00:00:00 2001 From: Luca Palmieri <20745048+LukeMathWalker@users.noreply.github.com> Date: Mon, 7 Jul 2025 13:23:09 +0200 Subject: [PATCH] Apply suggestions from code review Co-authored-by: Dmitri Gribenko --- .../newtype-pattern/parse-don-t-validate.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/idiomatic/leveraging-the-type-system/newtype-pattern/parse-don-t-validate.md b/src/idiomatic/leveraging-the-type-system/newtype-pattern/parse-don-t-validate.md index a1312e2b..d5bdfc4a 100644 --- a/src/idiomatic/leveraging-the-type-system/newtype-pattern/parse-don-t-validate.md +++ b/src/idiomatic/leveraging-the-type-system/newtype-pattern/parse-don-t-validate.md @@ -48,13 +48,15 @@ impl Username { can't modify it. - Stress the importance of evaluating _the entire API surface_ exposed by a - newtype to determine if invariants are indeed bullet-proof.\ + newtype to determine if invariants are indeed bullet-proof. + It is crucial to consider all possible interactions, including trait implementations, that may allow users to bypass the invariants. For example, if the `Username` type implements the `DerefMut` trait, users can modify the underlying string directly, bypassing the validation checks in `new`. -- Type-level invariants have second-order benefits.\ +- Type-level invariants have second-order benefits. + The input is validated once, at the boundary, and the rest of the program can rely on the invariants being upheld. We can avoid redundant validation and "defensive programming" checks throughout the program, reducing noise and