[ajross]

> In Rust, the compiler does that for you.

No it doesn't? That comment is expressing a human analysis. The compiler would allow you to stuff any pointer in that you want, even ones that overlap. You're right that some side effects of the runtime can be exploited to do that analysis. But that's true of C too! (Like, "these are two separate heap blocks", or "these are owned by two separate objects", etc...). Still human analysis.

Frankly you're overselling hard here. A human author can absolutely mess that analysis up, which is the whole reason Rust calls it "unsafe" to begin with.

[steveklabnik]

I think you're misunderstanding of what I'm claiming is being checked. I don't mean the unsafe block directly. I mean that &mut Ts do not alias. That is checked by the compiler.

I'm saying that even in a codebase with a lot of unsafe, the checks that are still performed have value.

[ajross]

Sure, but C++ objects returned from operator new are likewise guaranteed not to alias. There's "value" there, but not a lot of value. And I repeat, you're overselling hard here. People who write rust like this are going to produce roughly the same amount of memory safety bugs, and pretending otherwise is frankly dangerous, IMHO.

[sophacles]

The difference is:

In c++ i could do something like:

x_ptr = new object y_ptr = x_ptr

copy(x_ptr, y_ptr)

In safe rust there is no way to call the function in question if that sort of aliasing has happened. This means that if you get a bug from your copy, its in the copy method - the possibility it's been used inappropriately has been eliminated.

It reduces the search space for problems from: everywhere that created a pointer that is ultimately used in the copy, to: the copy function itself.

It reduces the number of programmers who have to keep the memory semantics of that copy in their head from "potentially everyone" to just "those who directly implement and check copy".

Pretending that has no value is absurd.