[uecker]

I understand this perfectly. The point is that 1) memory safety is a small part of the overall picture. 2) in practice people will not build perfectly safe abstractions that are then used by 100% memory-safe code, but they will create a mess.

[Georgelemental]

> In practice people will not build perfectly safe abstractions that are then used by 100% memory-safe code

Yes, in practice they quite commonly will. `unsafe` is rare, so it’s feasible to spend lots of extra efforts to validate it.

[uecker]

Is it rare? I see it a lot, especially in scenarios where speed matters, or where you need to interface with another system.

[steveklabnik]

I mean, it depends on what you mean by "rare."

Some projects will have more than others, for example, as you mention, interfacing with other systems or hardware. (Performance is not as straightforward.)

Even then, generally speaking it's usually pretty small: the sorta-kinda-RTOS we have at work for embedded systems is about 3% unsafe in the kernel, for example.

Surveying all of crates.io [1] almost a year ago found that 20% have 'unsafe' somewhere in them; this is expected to be higher on crates.io than in all Rust code, because crates.io hosts mostly libraries, which are going to use unsafe more than application code.

However, they also found that most of those usages of unsafe are for FFI, which is not able to be done in a safe way, and is overall easier to ensure the safety of than other forms of Rust's unsafe.

1: https://rustfoundation.org/media/unsafe-rust-in-the-wild-not...