The capability is internally a pointer to a monotonic GC-allocated object.
That capability pointer is always stored and loaded using monotonic 64-bit accesses.
Therefore, in the worst case you'll get a pointer that is torn from its capability, and then you'll trap accessing that pointer. But you'll never get a corrupt capability.
If you don't want the pointer to tear from its capability, just use `_Atomic`, `volatile`, or `std::atomic`. Then Fil-C uses lock-free shenanigans to make sure that the capability and pointer travel together and don't tear from one another.
Okay, in that case I do think one of the data-holding types in rust is a fair comparison, adding some runtime checks to let you be looser about ownership. Then you can write a function to split/share an array without a single bit of unsafe code.
I think the disconnect here is that some people want their data races (a) not to result in memory safety violations; some people want them to also (b) not result in nonsensical control flow or code producing results that look impossible, and some people want (c) data races to simply not occur.
You seem to like (a), Linus Torvalds seems to like (b), and Rust targets (c).
Rust doesn’t target (c). That’s a hugely disingenuous claim.
The truth is: Rust’s approach to memory safety only works if you also have no data races. This makes it a strictly inferior approach to memory safety, since programs sometimes do have to race (sometimes it’s just the best solution). So, Rust has data race prevention not because it’s a good idea but because the whole language falls apart without it.
> Rust has data race prevention not because it’s a good idea but because the whole language falls apart without it.
In terms of the design goals and evolution of the Rust language, this is exactly backwards. Rust was originally conceived as a garbage-collected, green-threaded language designed for concurrent programming -- think something similar to Go but with a stronger type system and no data races. The ownership model was created, first as foremost, not for memory safety but to prevent data races; and, more broadly, to help programmers reason about the correctness of their code.
Midway through development, as people started using the language & getting a feel for it, the language designers realized that the ownership model was powerful enough to express not just data race freedom but full memory safety without needing a GC (some writing from this stage in Rust's development: https://smallcultfollowing.com/babysteps/blog/2013/06/11/on-..., https://pcwalton.github.io/_posts/2013-06-02-removing-garbag...). So they removed the GC, and that decision positioned Rust where it is today: a nicer, memory-safe "C/C++ competitor", popular for systems code where the performance overhead or runtime complexity of a garbage collector is considered unacceptable.
