Clarify "unsafe pollutes the module"

`unsafe` and `mod` are not magically linked, it’s entirely up to code authors to actively use privacy to limit limit the scope of unsafety and only expose safe APIs (or `unsafe fn`s).
pull/50/head
Simon Sapin 7 years ago committed by GitHub
parent 7dfcd07611
commit 79d7569b69
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -92,7 +92,8 @@ capacity violates the invariants of Vec (that `cap` reflects the allocated space
in the Vec). This is not something the rest of Vec can guard against. It *has*
to trust the capacity field because there's no way to verify it.
`unsafe` does more than pollute a whole function: it pollutes a whole *module*.
Because it relies on invariants of a struct field, this `unsafe` code
does more than pollute a whole function: it pollutes a whole *module*.
Generally, the only bullet-proof way to limit the scope of unsafe code is at the
module boundary with privacy.

Loading…
Cancel
Save