Buggy unsafe blocks can affect code anywhere (through Undefined Behavior, or breaking the API contract). However, if you verify that the unsafe blocks are corr

Buggy unsafe blocks can affect code anywhere (through Undefined Behavior, or breaking the API contract). However, if you verify that the unsafe blocks are correct, and the safe API wrapping them rejects invalid inputs, then they won't be able to cause unsafety anywhere. This does reduce how much code you need to review for memory safety issues. Once it's encapsulated in a safe API, the compiler ensures it can't be broken. This encapsulation also prevents combinatorial explosion of complexity when multiple (unsafe) libraries interact. I can take zlib-rs, and some multi-threaded job executor (also unsafe internally), but I don't need to specifically check how these two interact. zlib-rs needs to ensure they use slices and lifetimes correctly, the threading library needs to ensure it uses correct lifetimes and type bounds, and then the compiler will check all interactions between these two libraries for me. That's like (M+N) complexity to deal with instead of (M*N).