No. He clearly stated that usage of an "unsafe" implementation is safer in Rust than C/C++. See my other post.

Raw pointers, maybe. But not std::unique_ptr<>, if I understand Rust's concept here.

unique_ptr is unfortunately still unsafe (in the Rust sense): there's nothing in the language stopping use-after-move of the unique_ptr value itself (which is a null-dereference and undefined behaviour), nor references to the interior becoming dangling.

Owned data in Rust (which is all data by default, unlike C++ which must opt-in via unique_ptr) has stronger guarantees than those provided by unique_ptr. It's still possible to deref a unique_ptr after using std::move.

That may be technically true but in practice and rhetoric "unsafe" is often used in contexts with much broader, implicit connotations. For example, putting Rust-compiler-proven-safety as the top, first, or best feature to consider. In that context, saying "C++ isn't Rust-safe" is essentially defining Rust to be "better", not advancing a coherent argument that it is in fact better.