Warning

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

r? @aturon

CC @alexcrichton on if we want to take the opportunity to use the new raw tooling to do explicit lifetime management here.

Unfortunately, I doubt that there is a way to make the mutable part here safe while providing a blanket impl (because these are open-ended).

In general, before we bring this into the standard library, it would be helpful to have more information about the use cases (and better yet, some evidence that many clients would benefit). This is something that can easily be provided in an external library, so it should only be brought into core if it would be very widely used.

@aturon Ah, yes, I forgot about extension impls. Quite unfortunate, really. It'd be nice to be able to represent a closed set of types. (Closed in the extension meaning, not topological).

@aturon The use cases in rust-image are storing a Vec<P> where P: Pixel<T>, T: Primitive, and then accessing that vector as bytes for pixel-component operations. When sending arrays across the network, it'd also be useful to have this for primitive arrays, without having to do a loop and .write_be_u16, for example (if you need to do an endian swap, you can do it on the entire buffer before hand, though a buffered reader might suffice), though this is quite niche given general purpose, high-speed serialization libraries, and not hand-written hacky things.

I've begun a casual audit of unsafe code used by various libraries, and this is a core piece of rust-image, and I have a feeling this pattern is widely applicable to applications which need to work with representations.