Rust's Safety Is Effective

Let's say I write a wrapper around a large, complex c/cpp codebase. It's far far beyond my ability to read the code and understand when UB could occur. It's beyond anybody to read through the whole codebase start to finish absent a serious budget. The maintainers have documented some soundness invariants, but from the tone you infer they're only interested in calling out what they see as likely significant unsoundness.

For some use cases it still makes sense to use this library from Rust. Nobody could write a wrapper and promise it sound without an infeasible amount of work.

It's useful if the wrapper signals the difference between "this is unsafe because you need to uphold this documented soundness invariant" and "this is unsafe because I can't promise there isn't an undocumented soundness variant the wrapper could violate".

But but but! That kind of distinction makes sense to people integrating large codebases from memory-unsafe languages. People who write different kinds of Rust rightly think "WTF are you talking about, a chance of unsound is unsound is unsound, and you can't be unsound without the user invoking unsafe".

Right now I think the best compromise is to have the entrypoint of the whole library be unsafe (i.e. the constructor of every type), but all the fns you subsequently use be safe. The safety docs of that fn says that you the caller is promising the soundness docs of the underlying c/cpp library are complete and accurate, and that's probably not true.

This

- Technically complies with the informal unsafe spec: You can't have unsoundness as a user without writing unsafe

- Is practically useful in cases where the benefit of a large existing c/cpp codebase means you want to accept a little unsoundness

- Let's people who think this whole thing sounds crazy because the point of Rust is memory safety sleep sound at night because they couldn't accidentally end up using this.