pre-RFC FromBits/IntoBits

[joshlf]

@gnzlbg

Not really, but why can’t that be done with a custom derive? If it can, then it can just be done on a crate, without having to write any kind of RFC for it. The proposal ensures transitivity, so this derive doesn’t really need any kind of compiler support, it is purely syntactic.

Yeah, and I know that there was a proposal to have v0 of this just require manual impls. If you can have a custom derive, then v0 could use the custom derive (so that folks don't have to unsafe impl manually, which introduces a risk of unsafety), and have v1 be the move from custom derive to compiler-supported auto trait.

@gnzlbg

Which issues? For practical purposes transmute is just a memcpy , so if the source type is properly aligned and the destination type is properly aligned, which they must be, then there aren’t any alignment issues AFAICT. The same applies to “endianness”: since transmute is just a memcpy , the bytes will just be copied from the source to the destination. If you don’t take endianness into account when reinterpreting the bytes on the destination, you will get different results on big endian and little endian systems, but that is just how memcpy works, so that’s “working as intended”.

I'm referring to alignment of references. impl<T, U> Compatible<&T> for &U where U: Compatible<T> {} isn't safe in general because U may have higher alignment requirements than T, so it's not actually guaranteed that any valid &T is also a valid &U. Pre-RFC: Trait for deserializing untrusted input discusses some options here, but if you don't have compiler support, then your options are either somewhat unergonomic (use a macro that uses static_assert! under the hood) or unsafe (since the caller needs to verify alignment manually).