Rust 正試圖改寫一項長久以來幾乎不可見的前提：型別的值可以被搬到另一個記憶體位置，也可以在不執行解構子的情況下被「遺忘」。2026 年專案目標「Immobile types and guaranteed destructors」已獲接受，預定於 2026 至 2027 年推進編譯器實驗、RFC 與 Linux 核心實測。不過，「目標獲接受」不等於功能已定案或即將穩定；目前 Move 追蹤議題仍標示為實驗性工作，RFC 尚待批准。原始文件：https://github.com/rust-lang/rust-project-goals/blob/main/src/2026/move-trait.md
問題不只是 Pin 難用，而是「不可移動」放錯了層級
來源事實：現行 Rust 以 Pin<Ptr> 表達位址穩定性。它限制安全程式碼取得能移出底層值的存取方式，讓依賴固定地址的自我參照型別、侵入式資料結構與部分 Future 得以建立安全介面。Rust 官方文件也指出，Pin 的保證必須由與它互動的 unsafe 程式碼手動維持；欄位投影是否具有結構性 pinning，則由型別作者決定，沒有一套放諸四海皆準的規則。https://doc.rust-lang.org/stable/std/pin/index.html
新路線要把「不可移動」從某個存放位置的狀態，提升為型別本身的性質。提案中的自動 trait Move 代表型別可被重新配置位置；選擇 !Move 的型別，則必須從存在到完成解構都維持穩定位址。這不只是縮短語法，而是讓編譯器在泛型邊界直接知道某個值能否被移動。
合理推論：若這套模型成立，函式庫作者可少用一層「指標被 pin、底層型別可能不可移動」的間接推理，泛型 API 也能以 trait bound 明確傳遞能力。但它不會憑空解決建構問題：一個 !Move 值不能先在暫存位置建好再搬到目的地，因此原提案明確依賴 in-place initialization，讓建構子直接寫入最終位置。
Guaranteed destructor 補的是另一個語意缺口
位址穩定與解構子必定執行是兩件事。提案將能力拆成 Move、Destruct 與 Forget：分別描述能否搬移、能否在離開作用域時隱式解構，以及能否透過 mem::forget 跳過解構子。這種拆分允許「不可移動、但仍可正常清理」的自我參照型別存在，而不必把所有能力綁成同一組限制。
現行 mem::forget 是安全函式，會取得值的所有權，卻不執行其解構子。官方文件解釋，Rust 的安全保證原本就不承諾解構子一定執行：安全程式碼可以形成 Rc 循環，也可直接呼叫 process::exit。因此，unsafe 程式碼不能假設呼叫端必然清理它交出的值。https://doc.rust-lang.org/stable/std/mem/fn.forget.html
這正是安全版 async scoped spawn 的障礙。其理想模式是：子工作可借用父作用域中的資料，而工作控制代碼離開作用域時會在解構子中 join。若呼叫端能忘掉控制代碼，子工作便可能活得比借用資料更久。提案認為，讓控制代碼採用 !Forget，即可在型別層阻止這條逃生路徑。相同基礎也被列為 async drop 與 pin-by-default 的前置能力，但原文件尚未提供這兩者的完整介面設計。
為何現在值得注意
第一，這已不是單純的社群文章，而是 Rust 2026 年正式專案目標，並由語言與型別團隊參與。第二，團隊把 Linux 核心列為現實驗證場域，因為 Rust for Linux 大量面對自我參照資料結構；其技術文章曾具體說明，安全地初始化 pinned 結構時，單靠現有借用與 Pin 模型會遇到難以封裝的問題。https://rust-for-linux.com/the-safe-pinned-initialization-problem
第三，編譯器實驗已有公開追蹤入口。該議題表示，所有型別預設仍實作 Move，只有主動選擇 !Move 者受到限制；初期範圍只驗證 trait 與編譯器檢查，不處理既有 trait 相容、Pin 遷移或進階 move constructor。https://github.com/rust-lang/rust/issues/149607
實際影響與容易忽略的限制
- 可能受益：自我參照物件、核心資料結構、非同步執行器，以及需要在作用域結束前完成清理或等待的函式庫，能把更多契約交由型別系統檢查。
- 不會立即改寫 Future：專案文件明列，本年度不修改穩定的
Futuretrait；它目前依賴Pin，遷移必須另立專案。 - 不是當機保證：依官方現行說明，程序直接結束或參照循環本來就可能略過解構。作者認為，「guaranteed」現階段不應解讀成斷電、abort 或程序崩潰時仍能完成交易；精確邊界仍待 trait 階層與既有功能的設計探索。
- 相容性成本尚未浮現：提案長期甚至希望淘汰
Pin，但 Rust 必須維持既有程式相容。新舊 API 很可能並存相當一段時間，函式庫也要決定何時值得採用更嚴格的能力界線。
對台灣開發團隊的意義
作者觀點：對以 Rust 開發嵌入式系統、核心模組、網路服務或非同步基礎設施的台灣團隊，近期最務實的做法不是預先重寫 Pin 程式碼，而是盤點哪些安全性假設依賴「一定會 drop」或「值絕不換地址」。前者在今天尤其危險，因為標準函式庫已明說呼叫端可以安全地忘掉值；後者則常藏在自我參照、原始指標與 FFI 邊界內。
後續應觀察四個指標：Move RFC 是否提出並獲語言團隊接受、編譯器實驗的效能與診斷品質、Linux 核心案例能否減少現有 unsafe 封裝，以及 Forget/Destruct 對 panic、程序終止、泛型容器與既有函式庫的規則。真正的里程碑不是新增幾個 trait 名稱，而是 Rust 能否在不破壞相容性的前提下，把資源生命週期從慣例提升為可由編譯器驗證的契約。