Hm, I ran into quite a lot of cases where I wanted Pin or something similar when porting a C program to Rust, and if I recall correctly also the creator of vulkano also ran into plenty of cases when writing it, so I am a bit surprised people did not realize this. My case was a program which in its C version was based around an epoll event loop, so maybe that is a bit similar to the async/generators issue.
When talking about Pin, I think it is important to go back to a more fundamental level.
There are types that are not movable without extra processing, like a `struct` that has fields that reference other fields. When moving, those references become invalid.
Rust chose by allowing types to become unmovable so the `struct` can't go into an invalid state.
While C++ doesn't have the same safety guarantees, they did need to solve this problem. C++ chose to solve this with move constructors. I know move constructors will have their own challenges in Rust but I hope we do get them one day.
#[derive(!Move)]Isn't `Pin` even crazier, in that the same type can be moveable (when used outside of Pin) or not moveable (when used inside Pin)? A simple derive wouldn't be enough to capture that.
The hypothetical opt-in moveability proposal is difficult to compare directly to `Pin` because they take such different approaches to the problem, but they would both address the problem (at least, as far as I have considered it).
I'd like to ask, why is moving generally useful? Why would I want to move x to y and invalidate x?
Does that make sense?
Here's an analogy: Rust already differs from most languages in that the behavior that you get "by default" when defining a new type is very limited. For example, if I define a type `struct Foo`, then by default this type can'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 move 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 actually 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.
The observation is that moving is a more fundamental operation than copying, therefore, it is easier for types to opt in to copying than to opt out.
When Rust was released in 2015 this was a relatively radical concept for a language targeting a mainstream audience (we're essentially describing Rust's entire concept of ownership here, after all). But it turns out that it's possible that Rust may not have been radical enough! Consider: what if you want a type that not only can't be copied, but can't be moved as well?
Before Rust 1.0 it wasn't clear that such a concept of "unmoveability" 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 do 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.
It wasn't until the async/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/await would become drastically less useful; there would be an entire fundamental part of the language that simply couldn'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).
For this reason I'm somewhat amused by one of the comments in the OP asking something like "if `Pin` had remained unstable for an additional year, would this particular instance of unsoundness have been caught?" 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.
(Regarding the bug in the OP itself, I think it's unfortunate but I'm not especially worried by it at this juncture. The fact that Ralf Jung'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'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.)