2 ms·
Hi, author of the code here. Why do I use mem::transmute? To highlight the fact that when using typestate, it's useful to understand operations that change the
by wcrichton 6y ago
Hi, author of the code here. Why do I use mem::transmute? To highlight the fact that when using typestate, it's useful to understand operations that change the the value of an object as distinct from those that change the type of an object. It's also a matter of efficiency -- you don't have to generate a new struct every time you change state.
You can avoid the overhead without transmute, but it's still unsafe and not easily explained: https://github.com/Munksgaard/session-types/commit/3a310d205cec567bed719d526d4a03c49825d583#diff-b4aea3e418ccdb71239b96952d9cddb6R200 https://github.com/Munksgaard/session-types/commit/3a310d205...
- kevincox 6y agoGenerating new structs is free in Rust. There is only cost if you need to send it somewhere and the layout differs from the original. Since `transmute` will be undefined behaviour if the layout differs you will only be saving cost if you would be invoking undefined behaviour. I recommend checking the generated asm and reporting a missed-optimization bug if it differs.
- lilyball 6y agoWhy can’t that just be written fn cast<E2, P2>(self) -> Chan<E2, P2> { Chan(self.0, self.1, PhantomData) }
- couchand 6y agoIn response to a challenge about the use of unsafe in the very first example of a blog post that you acknowledge doesn't need it, you respond with a defense of the code in some library. The differences between those contexts is massive; this seems central to the misunderstanding here. By applying a pattern that should rightly raise alarm bells for any seasoned Roast coder, you've distracted from your goal. By linking to a Reddit discussion rather than editing your post to clarify it, you've done your readers a disservice by drawing them into this muck.