[zozbot234]

> It will not include some key things which Rust makes safe because they can't see how to do that at all in their design.

To be fair, Rust does have an unsafe superset and the interaction between "safe" Rust and unsafe code is quite non-trivial. It's not safe to call any part of safe Rust from an unsafe context unless the extra preconditions that safe Rust expects (as documented in the 'Rustonomicon') are proven to hold. This means that, e.g. much of the Rust stdlib and 'core' code might not be practically usable from unsafe code written in either Unsafe Rust or C/C++, whereas the idiomatic C++ counterpart might be. There is some effort underway to fix this where it matters, but these are not easy questions to address.

[pitaj]

I don't really agree with how you represent the difficulties of unsafe Rust.

First off, unsafe Rust is not meant for writing application logic. It should be isolated within data structures, algorithms, or other abstractions exposing safe APIs.

Secondly, what you say about calling into safe Rust from unsafe contexts just doesn't sound correct. It seems like by "extra preconditions" you're talking about the requirements placed on references: that they must be initialized, non-null, and for &mut, unaliased. But these aren't requirements for calling into safe code, these are requirements for dereferencing raw pointers.

You might also be talking about the issues around moveability and Pin. But these are also not about calling into safe code, but about representing your type correctly (making certain actions only possible when pinned or whatever).

And then you talk about std and view not being practically usable from unsafe Rust, and this just doesn't align with my experience at all.

It's really not that hard to get unsafe code right (Miri is an awesome tool), and it's also not difficult to avoid unsafe code entirely if you're not comfortable with the requirements.

[zozbot234]

> these are requirements for dereferencing raw pointers.

You can use the unsafe read() and write() (and similar) functions to do things with raw pointers that would clearly involve dereferencing in C/C++ (including working with aliased pointers or 'pinned' data or writing to uninitialized memory), so I don't think this is correct from a C/C++ point of view. What Rust calls dereferencing is explicitly driven by the requirements placed on safe code; the two are effectively one and the same.