[mirashii]

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.

[kelnos]

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.

[ahepp]

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.

[cstrahan]

Not at all. Some things are fundamentally unsafe. mmap is inherently unsafe, but that doesn’t mean a library for it shouldn’t exist.

If you’re thinking of higher level libraries, involving http, html, more typical file operations, etc, what you’re saying may generally be true. But if you’re dealing with Direct Memory Access, MCU peripherals, device drivers, etc, some or all of those libraries have two options: accept unsafe in the public interface, or simply don’t exist.

(I guess there’s a third option: lie about the unsafety and mark things as safe when they fundamentally, inherently are not and cannot be safe)

[DetroitThrow]

>I guess I don't write enough rust to say this with confidence, but isn't that the bare minimum

I have some experience and yes, unless you're putting out a library for specifically low-level behavior like manual memory management or FFI. Trivia about the unsafe fn keyword missed the point of my comment entirely.

[DetroitThrow]

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.