Range 重生、斷言升級：Rust 1.96.0 帶來的語言層面大掃除
Rust Blog · 2026-05-28
Rust 1.96.0 於 2026 年 5 月 28 日正式釋出，這個版本以語言層面的「清潔工程」為主軸，修補了多年來在 Range 型別、型別推論與 WebAssembly 連結行為上遺留的設計疑慮。對日常開發影響最直接的，包括兩支新斷言巨集的穩定化，以及一套全新的 core::range 模組。這次同時修補了兩個 Cargo 安全性漏洞，建議所有使用者盡速升級。
全新 Range 型別：終於讓 Copy 和 Iterator 不再衝突
RFC 3550 的實作成果在此版本正式落地，於 core::range 模組下引入三個替代型別：core::range::Range、core::range::RangeFrom、core::range::RangeInclusive，以及對應的迭代器。過去標準函式庫的 Range 同時實作了 Iterator 和 Copy，在同一型別上同時具備這兩個 trait 是公認的「地雷」（footgun）——一旦將 Range 存入 Copy 結構體再拿來迭代，行為容易出人意料。
新的 core::range 型別改以實作 IntoIterator 取代 Iterator，因此可以安全地成為 Copy。舊語法 0..1 目前仍產生舊型別，新型別需透過 core::range::Range { start: 0, end: 1 } 或未來 edition 的遷移路徑取得。此外，NonZero<T> 範圍的迭代支援也在本版同步落地，讓非零整數範圍能直接用於 for 迴圈。
assert_matches! 與 debug_assert_matches! 正式穩定
兩支期待已久的巨集 assert_matches! 與 debug_assert_matches! 在 1.96.0 穩定化，讓開發者得以直接對值進行模式比對式斷言，取代過去冗長的 assert!(matches!(value, pattern)) 寫法。它們的優勢在於斷言失敗時能輸出更清晰的除錯訊息，方便精確定位問題所在。
值得注意的是，這兩支巨集沒有被加入 prelude，因為部分第三方 crate 已自行定義同名巨集，若直接加入 prelude 將引發命名衝突。使用時需明確 use std::assert_matches::assert_matches; 或以完整路徑呼叫。
use std::assert_matches::assert_matches;
let x: Option<i32> = Some(42);
assert_matches!(x, Some(n) if n > 0);
// 失敗時輸出詳細的不符合訊息，優於 assert!(matches!(..))
WebAssembly 目標：未定義符號從此變成連結錯誤
Wasm 目標不再自動傳遞 --allow-undefined 給連結器，這代表原本被靜默視為「外部匯入」的未定義符號，現在會直接導致連結失敗。這項變更能提前捕捉環境配置錯誤，避免在執行期才發現模組匯入表有誤。若有合法的跨模組匯入需求，可透過 RUSTFLAGS=-Clink-arg=--allow-undefined 恢復舊行為。
此外，型別層面也有數個相容性破壞（breaking change）值得留意。#[repr(Int)] 列舉的記憶體佈局在含有未填充零大小欄位的邊緣情形下已修正；Pin<Foo> 的 unsize coercion 現在要求 Foo 必須實作 Deref；AVR 目標上的 c_double 從 f64 改回 f32 以符合 C 規格。編譯器最低外部 LLVM 版本需求也從 19 提升至 21。
Cargo 修補：兩個 CVE 與 git + registry 雙源支援
Cargo 修補了兩個安全漏洞：CVE-2026-5223（中等嚴重性，符號連結解壓縮漏洞）與 CVE-2026-5222（低嚴重性，URL 驗證問題）。crates.io 使用者不受影響，但在本地使用 Cargo 下載套件包的情境應盡速升級。
功能面上，Cargo 現在允許依賴項同時指定 git repository 與備用 registry：本地開發時使用 git 版本，發佈後自動切換為 registry 版本，解決了長期以來在開發函式庫時需要手動切換依賴來源的痛點。Rustdoc 方面，廢棄標記（deprecation notes）的排版從 white-space: pre-wrap 改為標準 Markdown 渲染，多行廢棄說明需以兩個空格加換行符來分段。
六年磨一劍，終究未出鞘：Fornjot 宣告關閉的反思錄
Fornjot Blog · 2026-06-19
Fornjot 是一套以 Rust 撰寫的開源 b-rep（邊界表示法）CAD 核心，由 Hanno Braun 獨力開發近六年。2026 年 6 月 19 日，Braun 在官方部落格宣布終止這個專案，理由是技術進度遠落後於預期，且他再也無法在道德上繼續接受贊助。這篇告別文並非單純的失敗聲明，而是一份誠懇的公開反思，對所有靠贊助維生的開源作者都有參考價值。
從樂觀出發，在地基工程中陷入泥沼
專案最初幾個月的進展讓 Braun 過度樂觀：b-rep 的早期實作相當順利，讓他以為後續只需線性推進即可。然而，幾何核心的複雜性遠超預期，每一層抽象都需要耗費大量時間重構與驗證，進度從線性成長變成了「挖到地下室才能蓋高樓」的循環。他估計，以當時的速度，還需要至少兩到三年才能提供真正比現有方案更好的使用者價值。
更根本的問題在於策略選擇：Braun 長期堅持「只做漸進式改良」的原則，每次修改都試圖保持系統可運行，從不允許自己做大規模的架構實驗或原型探索。這樣的謹慎雖然維持了程式碼品質，卻也讓他在需要跳躍式突破的關鍵時刻動彈不得。
過早接受贊助：把夢想賣給了支持者
2022 年，Braun 在仍處於深度基礎建設階段時開始接受贊助。他坦承這是「賣了一個夢」——贊助者相信的是尚未存在的產品，而他自己也一度相信那個夢能在合理時間內實現。當 2023 至 2024 年贊助收入下滑時，他面臨全職投入或乾脆退出的抉擇，卻選擇了兩者都不徹底的中間路線：把 Fornjot 降格為副業繼續維持。
他將「降格為副業」定調為整個歷程中最大的錯誤。 這個決定既無法為贊助者交付進展，也讓他自己長期處於兩難的心理負擔之下，最終消耗殆盡。若當時能更早做出要麼全力衝刺、要麼乾淨收攤的決定，或許後來的一年不會浪費在高成本、低產出的掙扎裡。
願景漂移與原型實驗來得太遲
專案中期，Braun 將定位從「code-first CAD 應用程式」轉向「通用 CAD 核心基礎設施」，試圖服務更廣泛的下游生態。這個願景轉移使目標受眾模糊化，也讓他在決定功能優先順序時缺乏清晰的使用者故事作為錨點。更晚的時候，他才開始做大規模的架構原型實驗——而這個探索本應在更早期就展開，且不應與主線開發混在一起。
這份反思錄的結語並不悲觀：Braun 說自己從中學到的遠超想像，對 b-rep 幾何、開源永續性與個人極限都有了更深刻的理解。Fornjot 的程式碼仍然公開，有興趣的人可以繼續研究其設計，但作為一個持續演進的產品，它正式在此畫下句點。這篇文章與同期的 Rust 基金會維護者資金計畫公告，形成了一個關於開源永續性的強烈對比。
Rust 維護者不再孤軍奮戰：基金會正式啟動維護者資金計畫
Rust Blog · 2026-06-02
Rust 基金會於 2026 年 6 月 2 日宣布啟動 Rust Foundation Maintainers Fund（RFMF），以制度化方式為 Rust 專案的核心維護者提供長期薪酬支持。這項計畫的法源基礎是 RFC 3931，由 Leadership Council 核准後正式生效。其核心訴求只有一個：讓真正在做事的人能夠靠做這件事維持生計。
Maintainer in Residence：接近全職的長期資助職位
RFMF 的旗艦計畫是「Maintainer in Residence（MiR）」，定位為一個接近全職的有薪職位，專門開放給正在維護編譯器、標準函式庫、cargo、clippy 等核心元件的既有貢獻者。工作時間分為兩部分：由各 team 指派的優先任務（大型重構、程式碼審查、功能解鎖、issue 管理、貢獻者輔導）以及維護者自主規劃的 Rust 專案目標。
補償採公開費率的統一定額結構，資助安排預設以年為單位持續更新，只要雙方滿意且資金充足就會延續。這與一次性的 grant 不同，目標是提供真正的職涯穩定性。RFC 未指定具體金額，但要求公開費率以維持透明度；首批 MiR 名單預計在數月內公布。
治理結構：Funding team 加上公司比例上限
為執行 RFMF，RFC 3931 設立了獨立的 Funding team，由 Leadership Council 或各頂層 team 任命成員，負責評估維護需求、審查申請、維繫企業贊助關係，並定期發布影響力報告。除 MiR 計畫外，RFC 也保留空間給較小規模的 Project Grants，以及針對特定 Rust Project Goals 的指定贊助。
為防止單一企業過度影響生態，RFC 明確規定：若 Funding team 成員在五人以下，任何單一公司或實體的代表不得超過一人；六人以上則不得超過兩人。 這條護欄參考了 Cargo team 等既有治理慣例，確保資金流入不會扭曲技術決策方向。
個人與企業如何參與
個人支持者可透過 GitHub Sponsors（rustfoundation） 捐款；企業則可選擇相同管道或直接聯繫基金會（contact@rustfoundation.org）洽談更大規模的合作。官方承諾「所有來自此基金的收入將直接用於支持 Rust 專案維護者」，主要透過 MiR 職位撥付，但也保留以 grant 或其他機制靈活運用的空間。
此計畫的誕生，呼應了近年多個開源生態面臨維護者過勞與斷層問題的背景。本期同欄 Fornjot 的關閉公告恰好是一個真實對照：缺乏可持續的資金結構，最終令有能力的工程師不得不退場。RFMF 是否能改變 Rust 生態的長期維護面貌，值得持續觀察。
原始來源：Rust Blog — Launching the Rust Foundation Maintainers Fund · RFC 3931