4 ms·

I thought the same, but it seems to me the logical conclusion is to mark "I've added no unsoundness compared to if you were using the library I'm binding to" as

I thought the same, but it seems to me the logical conclusion is to mark "I've added no unsoundness compared to if you were using the library I'm binding to" as safe, and add in the docs homepage a general vibe of how sound the bound library is. When I suggested this on the Rust Reddit enough people thought this was a fundamental insult to the principles of what Rust means to them I decided not to do this.

timidger 6y ago
Do you have a link to that discussion?
- nicoburns 6y ago
  https://www.reddit.com/r/rust/comments/mxiufr/when_soundness_isnt_worth_it/ https://www.reddit.com/r/rust/comments/mxiufr/when_soundness... I was one of the people who commented on that post. My point was basically that "you need to uphold invariants in order for this to be sound" is exactly what `unsafe` means in Rust. So if you're wrapping a library that doesn't guarantee safety then you should mark it as unsafe (and there's nothing wrong with that). Rust library users will typically assume that they can do absolutely whatever they want with a safe interface and they cannot possibly cause memory safety issues, undefined behaviour, etc. A large part of the benefit of Rust is not even having to think about that. So it's important that libraries continue to stick to this convention.
mlindner 6y ago
I think the discussion on Reddit you're referring to was saying something slightly more nuanced than that. The case I specifically remember was someone arguing that simply passing through a C library function call without making it clear certain invariants needed to be held in the calling Rust code to not cause undefined behavior was somehow "safe". If you're wrapping a C call with some Rust code and you don't ensure all the invariants that could crash the C code are taken care of, then your function is still unsafe. If you do ensure that all the invariants are taken care of that could crash the C code are taken care of, then it's fine to have it be safe.

timidger 6y ago

Do you have a link to that discussion?

nicoburns 6y ago
https://www.reddit.com/r/rust/comments/mxiufr/when_soundness_isnt_worth_it/ https://www.reddit.com/r/rust/comments/mxiufr/when_soundness... I was one of the people who commented on that post. My point was basically that "you need to uphold invariants in order for this to be sound" is exactly what `unsafe` means in Rust. So if you're wrapping a library that doesn't guarantee safety then you should mark it as unsafe (and there's nothing wrong with that). Rust library users will typically assume that they can do absolutely whatever they want with a safe interface and they cannot possibly cause memory safety issues, undefined behaviour, etc. A large part of the benefit of Rust is not even having to think about that. So it's important that libraries continue to stick to this convention.

mlindner 6y ago

I think the discussion on Reddit you're referring to was saying something slightly more nuanced than that. The case I specifically remember was someone arguing that simply passing through a C library function call without making it clear certain invariants needed to be held in the calling Rust code to not cause undefined behavior was somehow "safe". If you're wrapping a C call with some Rust code and you don't ensure all the invariants that could crash the C code are taken care of, then your function is still unsafe. If you do ensure that all the invariants are taken care of that could crash the C code are taken care of, then it's fine to have it be safe.