Chrome engineers are experimenting with Rust. For the foreseeable future, C++ is the reigning monarch in our codebase, and any use of Rust will need to fit in with C++ — not the other way around. This seems to present some C++/Rust interoperability challenges which nobody else has faced.
We'd need to solve these before considering Rust as (nearly) a first-class citizen in our codebase. If we can’t solve these, Rust would at best be isolated to “leaf nodes” which don’t interact much with the rest of our codebase. And if that’s all we can use Rust for, that calls into question whether the costs of an extra language are justified in the first place.
This library provides a safe mechanism for calling C++ code from Rust and Rust code from C++, not subject to the many ways that things can go wrong when using bindgen or cbindgen to generate unsafe C-style bindings.
This doesn't change the fact that 100% of C++ code is unsafe. When auditing a project, you would be on the hook for auditing all the unsafe Rust code and all the C++ code. The core safety claim under this new model is that auditing just the C++ side would be sufficient to catch all problems, i.e. the Rust side can be 100% safe.
What happens when a data collection is copied and then the new copy is changed? Does the original remain the same, or does it change too?
If you think of copying as creating a completely new object, of course you expect that any change to the new copy does not affect the original object. But if you think of copying as creating a new name for the same, single object, then you expect that any change to the object through the new name appears also when you access the same object through the old name.
View all tags