[torginus]

Oh god, I hope I read this wrong. I thought Rust finally fixed C/C++'s worst issue which is aliasing, which means that if you pass a struct by pointer to a function, since any number of other mutable references might exist to it, the only correct way to treat it, is to reload/save it to memory every time you access it.

This is obviously unacceptable from a performance point, so compilers have resorted to heavy static analysis, and a bunch of hacks to prove nobody else is actually writing to that memory.

These hacks were brittle, leading to buggy or slow code, which is why C introduced the __restrict__ keyword, that allowed the programmer to tell the compiler that nobody is going to write to said variable, which meant it was now the programmer's responsibility to enforce that. High-perf code is littered with it.

I thought Rust's ownership system prevented mutable aliases, thus it allowed the compiler to automatically tag every pointer with __restrict__ , but if what the article says is right, Rust is bad as C/C++, because there are 1% exceptions to the general rule the compiler enforces.

[steveklabnik]

Rust tags every &mut T and every &T with the equivalent of restrict except for when the T transitively contains an UnsafeCell<T>. Types like Arc<T> and Rc<T> are built on top of UnsafeCell<T>.

Don’t use shared ownership? You get the semantics you want. It’s the norm for the vast majority of things.

[torginus]

Thanks for the answer, that sounds reassuring. I have another question, from what you said, it sounds like you remove restrict from the whol argument, but technically, afaict, the Rust borrow rules still prevent anything inside those structs getting aliased, with the exception of the stuff inside UnsafeCell<> (even with Rc<> the underlying value cannot be aliased, only the reference counter).

Does Rust/LLVM track aliasing to this degree, or is it all or nothing, like if you have a UnsafeCell anywhere, the whole type is excluded from restrict?

[steveklabnik]

I am not sure off the top of my head, to be honest. https://news.ycombinator.com/item?id=46616616 was a thread where I was talking about this sort of thing previously, you could probably adapt those code examples and get an answer.