Rust 2024: distinguish unsafe fn vs. unsafe blocks

[chriskrycho]

The former is no longer always treated as an unsafe block (without a warning, anyway), as implementation of RFC #2585 progresses; the unsafe fn declares an obligation and the unsafe block upholds it.

Fixes #4147

[matthias-t]

That was fast, thanks! I think it's a very good call to add this in a note block. I have a few issues with this version though:

• The change is being specifically introduced through editions, so newer versions of Rust will continue treating the bodies of unsafe functions as unsafe blocks unless a newer edition is selected. This is especially relevant as crate dependencies are allowed to use a language edition different from the dependent crate's.
• In the second sentence, I would welcome a reference to the fact that unsafe functions now behave just like normal functions in that respect. Maybe "even" before "in the body of an unsafe function"?
• I think I understand the third sentence, but I find it confusing. If I understand it correctly, you are giving a rationale for the change, and the second part refers to a place where the unsafe function in question might be called from. It would be clearer in my opinion to limit the argument to the function itself. Another way to express essentially the same argument is that it was not always desirable to have unsafe capabilities in the whole body of an unsafe function in order to keep unsafe blocks small. This has the added bonus of referring to the recommendation given earlier in the chapter.

I'd be happy to draft a PR if this is welcome.

[chriskrycho]

Feel free to draft a PR and we can iterate on it!

[chriskrycho]

One note: the reason I picked “version” rather than “edition” (which we can think about how best to address) is that we have not actually talked about editions at this point in the book, and the target audience for the book is new-to-Rust programmers. The fact that it’s technically over an edition rather than a version-only change is true but mostly irrelevant from the POV of a new learner who will get opted into edition: "2024" when they run cargo new. There are a bunch of places in the book where we just assume the current edition (whatever that may be at a given time), so it’s mostly “fine” to do the same here.

[matthias-t]

Great, I'll send in a draft in the next few days!

Fair point. This might be another place where the roles of the Book as an introduction to and as a documentation of Rust conflict. However, I would still argue that it's okay to use the term "edition" there with a reference to Appendix E. Editions are already mentioned in this way in Chapter 1.3, so they should not sound entirely foreign. And by the time the reader has come to chapter 20, or is familiar enough with the language that its topics are relevant to them, in the unlikely case that they are unaware of editions, looking to the appendix is probably a worthwhile digression. (For example because they are likely to come into contact with foreign code sooner or later.) Another advantage of mentioning editions is that it avoids creating the impression that Rust sometimes undergoes such breaking changes without accomodations for backwards-compatibility.