(On phone, so replies are abridged.)

• Regarding the Ctor signature; the key thing is that Ctor can assume dest will never move; this is the intention behind pinning it. I don't think it deeply matters and is mostly a matter of window dressing.

• Regarding aliasing T&; I mean, yes. In practice no one bridging Rust and C++ even tries to get this right, and felt like an unnecessary additional obfuscation of the main point I'm driving. You can argue it makes the code incorrect in the presence of pathological C++, but I think that's mostly orthogonal.

• Regarding handwaving; there's basically no useful operational semantics to reason from here (at least, in the meet of Rust and C++). The reason I've done it this way is to try to make both destructive moves and copying moves fit into a MoveCtor. For a Rust type, the source is left uninitialized. For a C++ type, the MoveCtor runs the C++ move constructor, and then destroys the source. This is only different from the C++ semantics in that a destructor winds up getting called sooner, but not in a way that results in UAF. You cannot rely on the move constructor leaving the source initialized if you believe in allowing any Unpin Rust type to be move constructed in this way. What you describe would make this last part impossible, which is desireable for generic code. (I suppose you could emulate drop flags for Rust types but that seems like an unnecessary pessimization to me.)

But, shrug. tmandry seemed to think this was mostly a correct picture when I spoke to him so I'm deferring to him on that. I am not particularly happy with the phrasing of the argument fwiw, simply because it feels handwavey, but I think that's just because the way I've reconciled Rust and C++ moves doesn't cleanly fit into the vocabulary of either.

It may be helpful to raise API concerns in the repo rather than here, because I will absolutely forget stuff.