Adam Reichold

> AFAICT, the generated visit_map is able to handle struct fields being present in any order, even though the generated Serialize::serialize always writes the fields in declaration order. If visit_map...

> Any thoughts? I think the type-state approach to `Universe` is definitly nice and `Send+Sync` could be modeled on top of that. I do also think that passing e.g. `&universe`...

> Just catching up now on session types: doesn't this mean you have to encode everything that can be sent/received when you create the pair (or group)? That seems exceedingly...

> I removed the public `safe-transmute` dependency (though still use it in an example) and added the desired traits myself. I updated the MR text to reflect this. That release...

I see two concerns here: 1. I would like to see `MaybeUninit` included in the fold so that I can still receive arbitrary data types which are not safe to...

@AndrewGaspar One thing I am wondering about here is usability. More specifically whether it is truly worth it to split the write and read sides of the equivalence traits. Is...

> Here's the problem: if we roll EquivalenceFromAnyBytes up into Equivalence, then we can't require MaybeUninit in the cases where it's not safe to write arbitrary bytes into T. I...

> One last question on my mind is whether there is a trait in safe-transmute that we could use instead of EquivalenceFromAnyBytes? It does feel a bit like reinventing TriviallyTransmutable?...

> Take one last look? One more idea I had concerning usability: Maybe we should make `EquivalenceFromAnyBytes` a sub trait of `Equivalence` as it really only makes sense for a...

> I don't know, I think I'm still leaning towards keeping them as separate derives because I think that's the maximally flexible option. Alright. I'd say we keep it as-is...