Unsoundness in Pin
For those who haven&#x27;t heard of `Pin` before (which is reasonable even for Rust users, for whom this is a rather obscure corner of the standard library): it&#x27;s essentially a trait that indicates that a value cannot be moved from its current location in memory.<p>Here&#x27;s an analogy: Rust already differs from most languages in that the behavior that you get &quot;by default&quot; when defining a new type is very limited. For example, if I define a type `struct Foo`, then by default this type can&#x27;t be copied around: `let x = Foo; let y = x;` is a simple operation that in most languages would involve copying memory, but in Rust involves a <i>move</i> instead. You can think of a move as a copy where the original value is no longer accessible (whether or not any bytes in memory <i>actually</i> get copied as a result of a move is an implementation detail, and is (hopefully) often optimized away). In order to make our type copyable, we would add an implementation of the `Copy` trait.<p>The observation is that moving is a more fundamental operation than copying, therefore, it is easier for types to opt <i>in</i> to copying than to opt <i>out</i>.<p>When Rust was released in 2015 this was a relatively radical concept for a language targeting a mainstream audience (we&#x27;re essentially describing Rust&#x27;s entire concept of ownership here, after all). But it turns out that it&#x27;s possible that Rust may not have been radical enough! Consider: what if you want a type that not only can&#x27;t be copied, but can&#x27;t be <i>moved</i> as well?<p>Before Rust 1.0 it wasn&#x27;t clear that such a concept of &quot;unmoveability&quot; would be generally useful. There were certainly cases, such as self-referential structs, that could have benefited from such a concept, however making moveability opt-in rather than opt-out would have required all types that <i>do</i> want to be moveable to explicitly announce that fact (via something like `#[derive(Move)]`), which is an annotation burden on all other code that must be considered.<p>It wasn&#x27;t until the async&#x2F;await work that another, more critical need for unmoveability was found: if the generators interally produced by `async` are capable of moving, then that means that generators are incapable of containing references, which means that async&#x2F;await would become drastically less useful; there would be an entire fundamental part of the language that simply couldn&#x27;t be used with it. Thus `Pin` was born in order to denote things that cannot be moved (and whose design is itself a very, very long discussion).<p>For this reason I&#x27;m somewhat amused by one of the comments in the OP asking something like &quot;if `Pin` had remained unstable for an additional year, would this particular instance of unsoundness have been caught?&quot; Because, conversely, we could ask whether Rust itself could have remained unstable for another five years and found a design that would have obviated `Pin` entirely by making moveability opt-in. However, of course, such things are easy to ask in hindsight, and stability is a prerequisite for having a broad base of adoption. Finding a balance between immediate stability and eventual perfection is the holy grail of industrial language design.<p>(Regarding the bug in the OP itself, I think it&#x27;s unfortunate but I&#x27;m not especially worried by it at this juncture. The fact that Ralf Jung&#x27;s team is looking into it gives me confidence that formal methods will eventually be applied here to more thoroughly explore the soundness of `Pin` in general (Ralf being one of the people who shaped `Pin` originally), and in the meantime I wouldn&#x27;t be opposed to a band-aid fix, given that working extensively with `Pin` in the way shown in the OP is rare for normal users.)