You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In light of `unsafe extern`, we need to note that this is another
position that `unsafe` is allowed. While we're here, let's make some
further revisions to clean up the start of this chapter, including
separating off into a rule these allowed positions.
Co-authored-by: ehuss
It plays several different roles, depending on where it is used and whether the `unsafe_op_in_unsafe_fn` lint is enabled:
8
-
- it is used to mark code that *defines* extra safety conditions (`unsafe fn`, `unsafe trait`)
9
-
- it is used to mark code that needs to *satisfy* extra safety conditions (`unsafe {}`, `unsafe impl`, `unsafe fn` without [`unsafe_op_in_unsafe_fn`], `unsafe extern`, `#[unsafe(attr)]`)
5
+
The `unsafe` keyword is used to create or discharge the obligation to prove something safe. Specifically:
6
+
7
+
- It is used to mark code that *defines* extra safety conditions that must be upheld elsewhere.
8
+
- This includes `unsafe fn`, `unsafe static`, and `unsafe trait`.
9
+
- It is used to mark code that the programmer *asserts* satisfies safety conditions defined elsewhere.
10
+
- This includes `unsafe {}`, `unsafe impl`, `unsafe fn` without [`unsafe_op_in_unsafe_fn`], `unsafe extern`, and `#[unsafe(attr)]`.
10
11
11
12
The following discusses each of these cases.
12
13
See the [keyword documentation][keyword] for some illustrative examples.
13
14
15
+
r[unsafe.positions]
16
+
The `unsafe` keyword can occur in several different contexts:
0 commit comments