# Safe Transmute ## How we see the world * Problems: * transmute `T` -> `U`: owned, immutable borrow, mutable borrow * transmute `&[T]` -> `&[U]` * Solution Groups: * `zerocopy` - using a bytes intermediary. No need to establish relationships between arbitrary types because everything goes through bytes. However, sometimes you need a sufficiently smart compiler to "do the right thing" * `typic` - using the type system to describe layout and then reason about the types in the type system * `Compatible<T>` - establish that two types are directly compatible with each other * Are we sure we want language feature support or would a good crate be good enough? * This would allow for better union support, and in order for this to not require `unsafe` we need language support. * We probably could do this in a library as long as we're ok with it not being direct field access * Specification improvements are needed in addition * Ryan: it's about trust and it's easier to trust the compiler over some third party library. "All safety critical features should be in the compiler" * Joshua: This is a good north star, but this will require a lot of expeirmentation in crates in order to figure out the right design. We should get to a point where we can move the solution from a crate almost directly into the std lib * Ryan: there are some core primitives that have been experimenting with that might already be good * Joshua: zerocopy has always been a stopgap and he believes that the highlevel APIs are definitely subject to change. * Jack: we should start from std::mem::transmute and try to slice up the problem to make that API safer * Is there a minimal amount we can do to get started on this path? * If we had a minimal set of primitive marker traits that we can use to mark types as upholding some memory invariants that will help a lot. * For example, "FromBytes/AsBytes" or "zeroed-padding" * Let's start at these marker traits and then go up to the high level APIs * One possible issue with marker traits: monomorphization errors * We might not need to be clever and just not care about errors that only become apparent at monomorphization errors * Typic gets around this by replicating the layout algorithm and encoding it into the type system * `Container<T>` might not be known to hold all layout invariants we need until after it's been monomorphized which would lead to the need for runtime checks which makes the API much less robust * What about const functions getting us out of this? * Being able to talk about this at the trait level so we can create generic functions which const functions doesn't allow for. * It is important that we have APIs that can make these assertions at compile time, so implementations that rely too heavily on runtime checks won't be workable * Is something like Typic possible with const? * Not really - you cannot say "implement this trait for all types where this const function is true" * Action items: * Shall we create a crate that contains core marker traits and try to build high level APIs? * Yes, we will add a repo online * Shall we rely on unstable monomorphization errors? * No, this ties us to a nightly compiler