2026-08-17 — Rust 標準庫導入 semver 自動檢查、C3 語言重新定位為泛用應用語言

Rust 標準庫接上 cargo-semver-checks，合併前自動攔截穩定 API 的破壞性變更

predr.ag（作者 Predrag Gruevski）· 2026-08-15

Rust 專案在 rust-lang/rust 倉庫中正式把 cargo-semver-checks 接入標準庫的建置流程，用來在合併前自動偵測對穩定 API 的破壞性變更。這項工作由 cargo-semver-checks 的作者 Predrag Gruevski 主導，分兩步完成：先以 rust-lang/rust#159671 新增一個獨立的 bootstrap 測試指令 x test std-semver-check（2026-07-29 合併），再由 rust-lang/rust#160253 把它接進正式 CI。推動這件事的原因是過去六年裡標準庫至少四次意外打破穩定性保證，而人工審查始終無法完全攔截這類問題。

背景

作者列舉了幾次歷史上的穩定性事故，全部都是「在合併時看起來沒問題，事後才發現破壞了下游」的案例。其中最新一次發生在 2026 年 3 月，直接促成了這次的工具化投資。

• 2020-09：在穩定 trait 上新增一個 unstable 方法，導致 async-std 編譯失敗（async-std#883）
• 2021-06：新增一個缺少 where 子句限制的泛型方法，使 BuildHasher 不再是 object-safe（rust-lang/rust#87991）
• 2022-07：一次疊代器健全性修正意外移除了 Send/Sync 實作（rust-lang/rust#100014）
• 2026-03：同樣是在穩定 trait 上加入 unstable 方法，造成 tokio 在 Windows 上編譯失敗，Rust 為此發出 1.94.1 緊急點版本（rust-lang/rust#153486）

核心改動

要讓 cargo-semver-checks 能分辨「破壞穩定 API」和「改動 unstable API」，rustdoc JSON 輸出格式必須先攜帶穩定性中繼資料。這部分由三個 PR 完成：rust-lang/rust#158230（2026-06-22 合併，新增 Item::stability 欄位）、rust-lang/rust#158343（新增 const_stability，對應 #[rustc_const_unstable]）、rust-lang/rust#158468（為 Function、AssocConst、AssocType 加上 default_unstable，處理 trait 預設實作）。核心設計是把「穩定性」當成一種可見性來處理：unstable 項目被視同 #[doc(hidden)]，在非 major 版本間允許被破壞，因此完全不需要重寫既有的 lint 規則，穩定性判斷是透過既有的可見性/隱藏分析自動生效的。

// rustdoc JSON 的 Item 結構新增欄位（節錄自 #158230）
struct Item {
    ...
    stability: Option<Box<Stability>>, // { level: Stable|Unstable, since, .. }
    const_stability: Option<Box<Stability>>,
}

x test std-semver-check 的執行流程是：用 git 找出父層 baseline commit，下載對應的 rust-docs-json CI 產物，對本地原始碼重新產生 JSON docs，再交給 cargo-semver-checks 比對兩份 API 快照。目前這個測試指令尚未預設執行、也還沒接進正式阻擋合併的 CI 檢查，CI 整合本身是 rust-lang/rust#160253 這個獨立 PR 的範圍。

影響範圍

作者也坦言目前的覆蓋範圍還不完整：檢查目前只在 x86_64 Linux 目標上執行，尚未涵蓋其他平台特定的破壞性變更；glob import 造成的邊界情況也還沒完全處理。後續的 UX 改善（例如如何更清楚地報告「這是 destabilization，不是真正的 breaking change」）則追蹤在 cargo-semver-checks#1672。

原始來源：predr.ag 部落格原文、rust-lang/rust#159671、rust-lang/rust#158230

C3 語言作者重新定位：這不是 C 的替代品，而是一門泛用應用語言

c3-lang.org（作者 Christoffer Lernö）· 2026-08-16

C3 語言作者 Christoffer Lernö 在專案部落格發表文章，重新界定 C3 的定位——不再稱它是「C 的替代品」，而是一門具備現代人體工學特性（動態字串、動態陣列、map）的泛用應用語言。文章發布於 2026-08-16，緊接在上一篇介紹 C3 0.8.3 feature flags 功能的文章之後。整篇文章的核心論點是「方法優先（methods-first）」的物件導向式思維，會在不自覺間限制程式架構的彈性，而這正是他過去把 C3 包裝成「C 替代品」時所忽略的問題。

核心改動

這個轉折來自作者維護一套 PHP 舊系統的經驗：那套系統表面上是物件導向，底層卻幾乎完全是程序式邏輯拼裝而成。他發現過度強調 OOP 架構分層，並不會讓開發速度或程式碼品質變好，反而是「先寫程序、再視需要抽象」的路徑更利於在問題空間中反覆試探。他把這個對照收斂成一個具體判斷：foo.do_something(bar) 這種方法優先的呼叫語法，會誘使人在還沒想清楚資料流向前就先決定「這個行為屬於哪個物件」，而 run(&game) 這種自由函式風格則把資料結構和行為解耦，重構時改動範圍更小。

// 方法優先（methods-first）
foo.do_something(bar);

// 程序式（procedural）
run(&game);

C3 目前仍保留方法（methods）語法，原因是要避免函式多載（overloading）的需求——例如讓 foo.to_string() 比自由函式呼叫更直覺。作者也承認這個設計選擇有其代價：方法語法本身可能在不自覺間強化「方法優先」的思維慣性，這和他現在想推廣的程序式優先方向存在張力。他以 Odin 語言作為對照組：Odin 從語言設計之初就沒有方法語法，因此更徹底地維持了程序式的思維習慣。

影響範圍

這篇文章代表的是 C3 專案敘事上的轉向，而非一次語法或編譯器層級的改動：從「C 語言的現代替代品」改為「具備 C 級別簡潔性、但貼近當代開發習慣的泛用應用語言」。目前最新穩定版本為 C3 0.8.3（2026-08-12 發布），已加入 Windows aarch64 支援與巨集的 GDB 除錯相容性等變更，專案原始碼與 issue 追蹤位於 c3lang/c3c。作者沒有在文中承諾要移除或弱化既有的方法語法，但這篇定位反思，為後續是否進一步向「程序式優先」調整語言設計，留下了伏筆。

原始來源：c3-lang.org 部落格原文、c3lang/c3c GitHub