Type-Level Programming in Rust

Re:Type-Level Programming in Rust by kd5bjo on Monday October 05, 2020 @02:25PM (#24690477)

> In practice, these particular examples are at least 99.9999% sure to do the right thing in all versions of Rust ever

I’m pretty sure that declaring both `Item` and `SecureVec` as `#[repr(transparent)]` would cover that last 0.0001% chance: it protects against the extra fields becoming non-zero-size by accident and forces the binary representation to be identical to the first field.

At that point, he’s transmuting between things with the same representation; all that’s left to verify is semantics.

[ Parent | on HN ]

Re:Type-Level Programming in Rust by chrismorgan on Monday October 05, 2020 @02:36PM (#24690596)

I knew there was another #[repr(…)] value, just couldn’t remember its name and didn’t look it up. Thanks for pointing it out. Yep, #[repr(transparent)] is a correct way of fixing the undefined behaviour—and if it won’t compile, then #[repr(C)] will do.

[ Parent | on HN ]

Re:Type-Level Programming in Rust by wcrichton on Monday October 05, 2020 @02:47PM (#24690698)

I didn't know about #[repr(transparent)], I will add that to the blog post. Thank you!

[ Parent | on HN ]