From 79d7569b693ea5b0225d4b912e34cd039e61d291 Mon Sep 17 00:00:00 2001 From: Simon Sapin Date: Sun, 24 Dec 2017 17:50:13 +0100 Subject: [PATCH] Clarify "unsafe pollutes the module" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `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). --- src/working-with-unsafe.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/working-with-unsafe.md b/src/working-with-unsafe.md index 09056c5..1864dd1 100644 --- a/src/working-with-unsafe.md +++ b/src/working-with-unsafe.md @@ -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.