From 6f0d1f8f41dc897ad748f7ceadc5a5ac13a320f5 Mon Sep 17 00:00:00 2001 From: Chris Krycho Date: Mon, 9 Dec 2024 10:47:39 -0700 Subject: [PATCH] Rust 2024: distinguish `unsafe fn` vs. `unsafe` blocks The former is no longer always treated as an unsafe block (without a warning, anyway), as implementation of [RFC #2585][rfc] progresses; the `unsafe fn` declares an obligation and the `unsafe` block upholds it. Fixes #4147 [rfc]: https://rust-lang.github.io/rfcs/2585-unsafe-block-in-unsafe-fn.html --- src/ch20-01-unsafe-rust.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/src/ch20-01-unsafe-rust.md b/src/ch20-01-unsafe-rust.md index 3e6147fe97..8796483a4b 100644 --- a/src/ch20-01-unsafe-rust.md +++ b/src/ch20-01-unsafe-rust.md @@ -186,9 +186,14 @@ With the `unsafe` block, we’re asserting to Rust that we’ve read the functio documentation, we understand how to use it properly, and we’ve verified that we’re fulfilling the contract of the function. -Bodies of unsafe functions are effectively `unsafe` blocks, so to perform other -unsafe operations within an unsafe function, we don’t need to add another -`unsafe` block. +> Note: In earlier versions of Rust, the body of an unsafe function was treated +> as an `unsafe` block, so you could perform any unsafe operation within the +> body of an `unsafe` function. In later versions of Rust, the compiler will +> warn you that you need to use an `unsafe` block to perform unsafe operations +> in the body of an unsafe function. This is because Rust now distinguishes +> between `unsafe fn`, which defines what you need to do to call the function +> safely, and an `unsafe` block, where you actually uphold that “contract” the +> function establishes. #### Creating a Safe Abstraction over Unsafe Code