Based off of documentation in the nomicon, it is safe to transmute a repr(transparent) type to its inner type because of the layout guarantees repr(transparent) provides. I using a repr(transparent) wrapper between ffi boundaries, and i transmute it to the underlying type when passing it to an ffi binding. Is there a way to codify that the transmutation is safe? What im looking for is some way to statically assert that the wrapper is repr transparent and its underlying type is the type i expect, so that if any of those two things were changed by someone, it would result in a compile error.
Deriving bytemuck::TransparentWrapper is a way to do this, but being a trait, it also makes the transmutability public, which might not be what you intend.
1 Like
Hmm. That's interesting, but you're right in that I don't what the transmutability to be a public thing. My wrapper does not declare its inner as pub, and would like to prevent end users from having access to things like peel.
Could you just not transmute anything at all, and instead implement 3 accessor methods) by reference, by mutable reference, ba value) on the wrapper?
1 Like
Ah, you're right. I was thinking that having public accessors would expose them to users of the crate, but as long as I keep the modules private and don't re-export the type, it would work.