The unsafe keyword has two roles

  1. Creating APIs with safety considerations

    • unsafe functions: unsafe fn get_unchecked(&self) { ... }
    • unsafe traits: unsafe trait Send {}

  2. Using APIs with safety considerations

    • invoking built-in unsafe operators: unsafe { *ptr }
    • calling unsafe functions: unsafe { x.get_unchecked() }
    • implementing unsafe traits: unsafe impl Send for Counter {}
This slide should take about 5 minutes.

Two roles:

  1. Creating APIs with safety considerations and defining what needs to be considered
  2. Using APIs with safety considerations and confirming that the consideration has been made

Creating APIs with safety considerations

“First, the unsafe keyword enables you to create APIs that can break Rust’s safety guarantees. Specifically, you need to use the unsafe keyword when defining unsafe functions and unsafe traits.

“When used in this role, you’re informing users of your API that they need to be careful.”

“The creator of the API should communicate what care needs to be taken. Unsafe APIs are not complete without documentation about safety requirements. Callers need to know that they have satisfied any requirements, and that’s impossible if they’re not written down.”

Using APIs with safety considerations

“The unsafe keyword adopts its other role, using APIs, when it is used nearby to a curly brace.

“When used in this role, the unsafe keyword means that the author has been careful. They have verified that the code is safe and is providing an assurance to others.”

“Unsafe blocks are most common. They allow you to invoke unsafe functions that have been defined using the first role.

“Unsafe blocks also allow you to perform operations which the compiler knows are unsafe, such as dereferencing a raw pointer.”

“You might also see the unsafe keyword being used to implement unsafe traits.