Warning

• These commits modify unsafe code. Please review it carefully!

@cgaebel: Since Vec<T> doesn't use repr(C), it would technically be undefined behaviour to rely on the on the representation. I still think it's worth having the order match Slice because in practice the compiler is only going to reorder fields when it reduces the size (never these) or if something like randomization is enabled for hardening.

Hmmm then would be make sense to mark both raw::Slice and Vec as #[repr(C)] ?

@cgaebel: I don't think Vec<T> should be repr(C). The Slice type does need to be repr(C) to have a guarantee of matching the compiler representation.

In the case where struct randomization isn't enabled, matching the representation of slices should allow more optimizations by LLVM. It does make sense to define it in the same order but that order being preserved is not guaranteed by the language.

Maybe I'm just not understanding what you're saying, but doesn't #[repr(C)] guarantee the order be preserved?

It does guarantee that, but tagging stuff as #[repr(C)] when it's not actually needed would make randomization less useful.