unsafe belongs on the extern block, not the call site

I follow Carbon more closely than Rust, and it is aiming at the other end of this. The plan is for Carbon code to import C++ headers directly, with no hand-written foreign declarations at all, so a mismatched signature has nowhere to be typed in. Whether the safety story holds up is still open. The project calls itself experimental and its memory safety design isn't finished, so anything said about Carbon's interop soundness for now is intent rather than behavior.

The signature is half of it. The other half is unwinding. A panic that tries to leave an extern "C" Rust function now aborts the process, and a C++ exception crossing into Rust is only defined through the "C-unwind" ABI. So the declaration also has to say whether anything can unwind through it. With an abort no destructor runs at all, so a handle that needed an orderly close never gets one.

This has a near twin in Swift's Sendable checking, which is where I usually run into it. C headers say nothing about which thread may touch what, so a wrapper around a C handle usually ends up marked @unchecked Sendable, and the compiler takes the author's word for it, much like a safe fn in a foreign block. I'd keep those rare and easy to grep, each with a comment naming the lock or queue that makes it true. And @preconcurrency import quietly downgrades a module's Sendable diagnostics, which is fine during migration and easy to forget afterwards.

Not quite the same sentence. @unchecked Sendable vouches for a type everywhere it travels, while a safe fn vouches for one foreign function's preconditions. Both should be easy to grep, and Rust at least forces the word unsafe onto the block that holds the vouching, so one search finds every claim.

Read the diff cargo fix --edition gives you on an FFI crate before trusting it. Adding unsafe to every extern block is expected, but it also wraps every unsafe fn body whole.

pub unsafe fn len_of(s: *const c_char) -> usize { unsafe {
    let n = strlen(s);
    n + abs(0) as usize
}}

That compiles under 2024 and keeps the lint quiet, and it is exactly what the lint exists to retire. No SAFETY comment, nothing to review. Split those by hand into one block per operation.

safe fn is left to you as well. A function that takes and returns an integer can become safe fn. One that takes a pointer stays unsafe until you can write an honest justification for it.