]> git.lizzy.rs Git - rust.git/blobdiff - src/doc/complement-design-faq.md
Auto merge of #21401 - kballard:optimize-shrink-to-fit, r=nikomatsakis
[rust.git] / src / doc / complement-design-faq.md
index 6cdaf96d3f50e3c7dc19fce994ac23887d32e094..e57953db3a256fd2463ad6a04d3015dccd830c96 100644 (file)
@@ -94,9 +94,9 @@ code should need to run is a stack.
 
 `match` being exhaustive has some useful properties. First, if every
 possibility is covered by the `match`, adding further variants to the `enum`
-in the future will prompt a compilation failure, rather than runtime failure.
-Second, it makes cost explicit. In general, only safe way to have a
-non-exhaustive match would be to fail the task if nothing is matched, though
+in the future will prompt a compilation failure, rather than runtime panic.
+Second, it makes cost explicit. In general, the only safe way to have a
+non-exhaustive match would be to panic the task if nothing is matched, though
 it could fall through if the type of the `match` expression is `()`. This sort
 of hidden cost and special casing is against the language's philosophy. It's
 easy to ignore certain cases by using the `_` wildcard: