Comment by ralfj
2 days ago
C has an opt-out that works sometimes, if a compatible type exists. Rust has an opt-out that works always: use raw pointers (or interior mutable shared references) for all accesses, and you can stop worrying about aliasing altogether.
I think that way of describing it is really weird.
In C, you do not use any special keywords to opt into or opt out of TBAA, instead it is the rule by default that one must follow. I do not consider that 'opting out'. One can disable that in some compilers by disabling 'strict aliasing', as the Linux kernel does, but that is usually on a whole-program basis and not standard.
In Rust, using raw pointers is using a different mechanism, and mutable references are always 'no aliasing'.
An example of opting in would be C's "restrict" keyword, where one opts into a similar constraint to that of Rust's 'no aliasing' for mutable references.
>use raw pointers (or interior mutable shared references) for all accesses, and you can stop worrying about aliasing altogether.
And dereferencing a raw pointer requires 'unsafe', right? And if one messee the rules up for it, theN UB.
Can you confirm that the interaction between raw pointers and mutable references still requires care? Is this comment accurate?
>It is safe to hold a raw pointer, const T or mut T, at the same time as a mutable reference, &mut T, to the same data. However, it is Undefined Behaviour if you deference that raw pointer while the mutable reference is still live.
> Can you confirm that the interaction between raw pointers and mutable references still requires care?
Yes, that still requires care.
> In C, you do not use any special keywords to opt into or opt out of TBAA, instead it is the rule by default that one must follow
That's exactly the problem: sometimes you need to write code where there's more aliasing, and C just makes that impossible. It tells you to use memcpy instead, causing extra copies which cost performance.
In Rust, you can still write the code without the extra copies. Yes, it requires unsafe, but it's at least possible. (Remember that writing C is like having all code be unsafe, so in a comparison with C, if 10% of the Rust code needs to be unsafe that's still 90% less unsafe than C.)
the opt-out in C is to use char*, which is specifically allowed to alias other types.
There are also GCC extensions to build other types that may alias.
That doesn't let you treat data in-place at two different types, unless one of them happens to be char. So you still need to make a copy in many cases, e.g. to convert between an array of uint32_t and an array of uint16_t.
In some cases you can use unions, but that, too, is very limited, and I am not sure it would let you do this particular case.
Not if you use may alias.
Also yes, that's the point of the C++ object model, only one type may exist in one location at a time.
Since usually different register banks are used for different types, having to copy makes sense.