Yeah I'm a bit confused because you can have an entirely unsafe code base with just the public interface marked as safe. No unsafe in the interface isn't a measure of safety at all.
It is a measure of the intended level of care that the users of your interface have to take. If there's no unsafe in the interface, then that implies that the library has only provided safe interfaces, even if it uses unsafe internally, and that the interface exposed enforces all necessary invariants.
It is absolutely a useful distinction on whether your users need to deal with unsafe themselves or not.
It's useful, to be sure, but I wouldn't want to use a library with a safe public interface that is mostly unsafe underneath (unless it's a -sys crate, of course). I think "this crate has no unsafe code" or "this crate has a minimal amount of carefully audited unsafe code" are good things to see, in general.
I guess I don't write enough rust to say this with confidence, but isn't that the bare minimum? I find it difficult to believe the rust community would accept using a library where the API requires unsafe.
Sure, it's a useful distinction for whether users need to care about safety but not whether the underlying code is safe itself, which is what I wrote about.
No or very little but verified unsafe internal code is the bar for many Rust reimplementations. It would also be what keeps the code memory safe.
mirashii|1 day ago
It is absolutely a useful distinction on whether your users need to deal with unsafe themselves or not.
kelnos|22 hours ago
ahepp|1 day ago
DetroitThrow|1 day ago
No or very little but verified unsafe internal code is the bar for many Rust reimplementations. It would also be what keeps the code memory safe.