It assumes using your library is safe, same way you assume Rust std is safe, even though it uses unsafe in the background.
Basically, burden of proof of using unsafe correctly is on the programmer.
Basically, burden of proof of using unsafe correctly is on the programmer.
A function like memmove would be completely unsafe in Rust for instance but C++ could expose such an interface without having to do anything special.
No. C++ programs are safe under certain conditions. If they aren't then they need to be changed in C++ or in Rust interfacing code.
Even if something is unsafe, it can still be used safely.
I entirely agree with this. My point is that these conditions are not always (and often aren't) encoded in the C++ syntax itself, and are instead part of the documentation or some softer coding convention.
As such an automatic code converter can't be aware of these details and can't decide if a call is safe or not. C++ doesn't have the concept of safety built in, it's the programmer that's in charge of keeping track of the soundness of it all. It's not enforced by the compiler like Rust does.
I'm really surprised that there's so much debate around this in this thread honestly (including by people who know Rust very well). That's blindingly obvious to me that it's a very bad idea. Clearly that means that I'm missing one side of this issue.
Publishing safe Rust APIs that are _intentionally_ unsound should at best be warned about to any other crate that depends on it. Ideally, those authors and their crate would simply be banned.
Either you change the C++ lib to not behave unsafely for inputs.
Or you manually change the binding to keep the invariant.
The assumption behind linking to C++ code is that it doesn't contain unsoundness. If it does the library was fucked way before.
But this discussion is about a tool that:
* does not change the C++ code to behave correctly for all inputs
* does not (and technically cannot) generate safe Rust bindings that keep the invariant (the bindings are automatically generated under the assumption that all C++ code is safe for all inputs).
I think this is already invalidated by countless code generation and build scripts.
Even regular safe Rust assumes you use unsafe in a proper manner.
This build tool assumes your C++ code is safe enough to wrap around unsafe trivially.
This build tool, as first proposed, knowingly exposed macros that can cause memory unsafety with the wrong inputs, without making you write unsafe. If a build tool makes assumptions like "you probably know what you're doing with that C++ code" without asking you to write unsafe, it is just as wrong as an implementation of unchecked indexing that wasn't marked unsafe (because "you'll probably know not to use this unless you're really in bounds."). It is clear that you consider this a trivial matter, but many people very heavily involved in the Rust community (including the people working on its soundness proofs) do not.
This was done to deal with remarks Chromium devs had against Rust C++ binding.
In lieu of that it's liberal treatment of unsafe is understandable.
I have a hard time believing those Chromium devs know what they want.
Their request allows safe Rust to introduce undefined behavior, making the unsafe Rust keyword meaningless (since now you can't even grep for the places in the code where this UB is introduced), and eliminating the actual reason they want to use Rust in the first place (to avoid undefined behavior, segfaults, CVEs, etc.).
The only thing complying with the request will achieve is hurt the language. Once the chromium devs start hitting the same CVEs and segfaults in Rust that they were hitting in C++, they will just tell the whole world that Rust is as bad as C++ and using it is not worth it.
Rust std wasn't yet verified to not contain unsafe behavior. In fact, some modelling discovered and fixed unsafe behavior in Rust std libs.
Same happens here. If you discover that for inputs you have unsafe behavior calling ffi, you uncapsulate it in way that prevents misuses or fix in source ffi lib.
Not a problem. Rust checks are applied to the Rust code you write or import, and everything else is just ingested as is.