> The obvious implementation is for unsafe to be infectious like const. You have unsafe code, your crate is unsafe. You depend on an unsafe crate, your crate becomes unsafe.

That would mean everything is unsafe, since every crate depends on core (or on std which depends on core), which has "unsafe" code.

The design of "unsafe" in Rust, instead, is to allow building safe abstractions on top of unsafe code (or be able to clearly mark when the abstraction itself is unsafe). That way, for instance, users of `Vec::push` do not have to worry that it uses uninitialized memory (which is unsafe).

This is a poor comment. You clearly don't understand how unsafe is to be used. No code (of significant size) that you run will be bug free ever. So you might as well start from that assumption and realize you are trying to minimize the amount of unsafe code and bugs; you will never remove all of them no matter what the language.

That would prevent you from using the stdlib.

https://doc.rust-lang.org/src/alloc/string.rs.html#1215-1230

Using unsafe doesnt necessarily mean you will have undefined behaviour, it just means you have to think really hard about the behaviour because the compiler won't have your back.

I wish there was a better way of handling that in Rust. You should be able to have a few markers in your code:

- uses unsafe - no unsafe, but dependencies may use unsafe - no unsafe, no dependencies except the standard library may use unsafe - no unsafe, not even in the standard library uses

The current situation is the second one, but many cases probably want the third, and occasionally the fourth.

The best part is, this should be fairly easily solved by crates.io upon submission (is there any use of unsafe and are all dependencies marked as strict or more strictly than yours?).