引入移动构造函数能否让Rust中的Pin/Unpin不再必要？

Pin/Unpin是Rust实现async/await的核心前置机制，它能安全地轮询那些可能包含自身状态内部引用的Future。不过曾有思路提出：给Rust引入移动构造函数，让Future在被轮询后仍能自由移动内存位置，所有内部引用由移动构造函数自动修正。示例代码如下：

async fn foo() { /* ... */ }

async fn bar() {
    let future = foo();
    poll_fn(|cx| future.poll(cx)).await;
    // 此时`future`可能已包含指向自身内部状态的引用
    let boxed_future = Box::new(future);
    // Future被移到堆上，但移动构造函数已经调整好内部引用，可安全再次轮询
    boxed_future.await;
}

这种方案当初确实被Rust团队考虑过，但最终被否决，核心原因如下：

• 语言复杂度与实现成本过高：移动构造函数要求编译器在对象移动时自动生成内部指针修正逻辑，这会大幅提升编译器实现难度，还会让语言规则变得晦涩难懂。Rust始终坚持简洁、可预测的设计原则，这类需要编译器大量隐式工作的特性不符合其设计理念。
• 运行时性能损耗：每次移动对象都要触发内部引用的修正操作，会带来额外的运行时开销。而Pin机制是编译期检查，几乎不会产生运行时成本，完全契合Rust零成本抽象的目标。
• 兼容性冲击过大：引入移动构造函数会破坏现有Rust代码的兼容性，大量依赖现有移动语义的逻辑都需要重新适配。而Pin是基于trait的扩展机制，对现有代码的侵入性极低。
• 场景覆盖存在局限：移动构造函数只能处理已知的内部引用，但Future的状态可能包含嵌套、动态生成的复杂引用，无法保证所有场景都能正确修正。Pin通过强制固定内存位置，从根源上避免了引用失效问题，可靠性更高。

内容的提问来源于stack exchange，提问作者rubo