diff --git a/src/doc/style/features/functions-and-methods/input.md b/src/doc/style/features/functions-and-methods/input.md
index 8d123bcec6bc..9ea1d2181619 100644
--- a/src/doc/style/features/functions-and-methods/input.md
+++ b/src/doc/style/features/functions-and-methods/input.md
@@ -147,23 +147,26 @@ Choose an argument type that rules out bad inputs.
 For example, prefer
 
 ```rust
-fn foo(a: ascii::Ascii) { ... }
+enum FooMode {
+    Mode1,
+    Mode2,
+    Mode3,
+}
+fn foo(mode: FooMode) { ... }
 ```
 
 over
 
 ```rust
-fn foo(a: u8) { ... }
+fn foo(mode2: bool, mode3: bool) {
+    assert!(!mode2 || !mode3);
+    ...
+}
 ```
 
-Note that `ascii::Ascii`
-is a _wrapper_ around `u8` that guarantees the highest bit is zero; see
-[newtype patterns](../types/newtype.md) for more details on creating typesafe wrappers.
-
 Static enforcement usually comes at little run-time cost: it pushes the
-costs to the boundaries (e.g. when a `u8` is first converted into an
-`Ascii`). It also catches bugs early, during compilation, rather than through
-run-time failures.
+costs to the boundaries. It also catches bugs early, during compilation,
+rather than through run-time failures.
 
 On the other hand, some properties are difficult or impossible to
 express using types.
@@ -176,7 +179,7 @@ downsides:
 
 1. Runtime overhead (unless checking can be done as part of processing the input).
 2. Delayed detection of bugs.
-3. Introduces failure cases, either via `fail!` or `Result`/`Option` types (see
+3. Introduces failure cases, either via `panic!` or `Result`/`Option` types (see
    the [error handling guidelines](../../errors/README.md)), which must then be
    dealt with by client code.