Zig 0.16.0：Io 介面重構與結構化並行基礎
LWN.net / ziglang.org · 2026-04-27
Zig 0.16.0 在 LWN 報導中被歸類為語言在結構化並行（structured concurrency）方向的重要探索。核心改動是對 Io 介面的大規模重寫，目標是讓標準函式庫的非同步 I/O 操作得以在不同執行環境（event loop、thread pool、blocking I/O）下互換，同時保持呼叫端程式碼不改動。
Io 介面設計
舊版 Zig 的非同步模型依賴 async/await 關鍵字與協程式的堆疊切換，但在 0.12 版本起被暫時移除，進入重設計階段。0.16.0 引入的 Io 介面採用 comptime dispatch：函式接受一個 Io 參數，該參數在編譯時期被具體化為實作（例如 Io.Blocking、Io.Epoll、或自訂實作）。這使同一個函式可在不同執行模型下執行，而不必在函式簽章中暴露非同步語意。
fn readFile(io: Io, path: []const u8) ![]u8 {
const file = try io.open(path, .{ .mode = .read_only });
defer io.close(file);
return io.readAllAlloc(file, allocator, max_size);
}結構化並行的意涵
結構化並行（由 Nathaniel J. Smith 在 Notes on structured concurrency 及 Trio 函式庫推廣）要求所有衍生的並行工作必須在創建它的作用域結束前完成，以確保資源生命週期可追蹤。Zig 的 Io 介面透過讓 I/O 操作的生命週期綁定到 scope，而非在全域事件迴圈上飄移，向此原則靠攏。
生態系影響
此版本破壞了大量依賴舊有 async/await 語義的第三方函式庫（包含 zig-network、http.zig、zap 等），遷移需要改寫 I/O 呼叫層。Zig 開發組表示 0.16.0 是探索性版本，Io 介面的 API 在下個大版本前仍可能調整。
原始來源：LWN — Zig explores structured concurrency、Zig 0.16.0 Release Notes
Linux 7.1-rc1：合併窗口關閉、i486 支援退場、AMD GPU 暫存器大規模同步
LWN.net / LKML · 2026-04-27
Linux 7.1-rc1 於 2026 年 4 月 26 日由 Linus Torvalds 發布，宣告 7.1 的兩週合併窗口關閉。本版共合入約 13,000 個非 merge commit，外加約 1,000 個 merge commit，整體規模 Torvalds 形容為「相當正常」。
i486 支援退場
7.1-rc1 正式移除了 i486 CPU 支援——在合併窗口期間，相關 CONFIG_ 選項的 Kconfig 定義已被刪除，餘下的程式碼刪除（C 與組合語言層面）預計在後續清理 commit 中完成。i486 缺乏 cmpxchg 指令（486 引入，Pentium 後普及），Linux SMP 與原子操作基礎設施長期需要特殊路徑處理，移除後可簡化核心原子原語與 x86 低層程式碼。
AMD GPU 暫存器標頭同步
本次差異統計中，約 25% 的 patch 來自 AMD GPU（amdgpu）驅動的暫存器標頭檔（register header）同步——這類自動生成的 C 標頭描述 GPU 硬體暫存器的位址與位域，每個 GPU 世代產生大量異動，但對核心功能的影響有限。
主要子系統合入
驅動程式佔變動量約 50%；檔案系統（btrfs、XFS、ext4、f2fs、erofs）、網路基礎設施、KVM 虛擬化、記憶體管理（mm）、以及 perf/tracing 子系統均有顯著更新。舊有 SoC 支援（「從未落地」的平台）與老舊網路硬體驅動亦在此版本中被一併清除，延續核心的技術債清理路線。
Cloudflare Rust Workers 0.8.0：Wasm Exception Handling 實現 panic 無損恢復
Cloudflare Blog · 2026-04-22
Cloudflare 於 2026 年 4 月 22 日發布 workers-rs 0.8.0，引入 --panic-unwind 構建標誌，利用 WebAssembly Exception Handling 規格讓 Rust Worker 在 panic 後無需重新初始化模組實例即可繼續服務後續請求。
WebAssembly Exception Handling 的技術基礎
WebAssembly Exception Handling 規格（現為 Wasm 1.1 的一部分）在 Wasm 指令集層面引入 try/catch/throw 指令，並定義 Exception Tag 機制：每個例外攜帶一個標籤（Exception.Tag），接收端可以標籤區分例外來源。主流引擎的支援時間線：Firefox 131（2024-10-01）、Safari 18.4（2025-03-31）、V8 13.8.1（2025-04-28）、Chrome 138（2025-06-28）、workerd v1.20250620.0（2025-06-19）、Node.js 25.0.0（2025-10-15）。
panic=unwind 的工作機制
啟用方式：以 RUSTFLAGS='-Cpanic=unwind' cargo build -Zbuild-std 重新編譯標準函式庫（需啟用 nightly 的 build-std 功能）。編譯後，Rust 函式邊界以 extern "C-unwind" 宣告，允許 unwind 穿越 FFI 邊界而不立即中止。
析構子（Drop）的正確執行依賴 Wasm 例外處理：堆疊上的 HasDropA、HasDropB 等物件，在 imported_func() panic 時仍會依正確順序執行 drop()，防止資源洩漏。
Panic 最終在 Rust-JavaScript 邊界以 JavaScript PanicError 例外形式浮現，外部 JS 程式碼可攔截並記錄，Worker 實例本身保持存活。
abort 恢復的額外設計
OOM 等 abort 情境無法 unwind。workers-rs 利用 Exception Tag 將 abort 例外與可 unwind 的 panic 例外區分，並透過 set_on_abort 鉤子讓平台實作自訂恢復邏輯。0.6.0 版本的舊有 Proxy 式 reinit 機制在未設置 --panic-unwind 時仍有效，保持向後相容。
ES Module 函式庫的 reset-state
作為實驗性延伸，--reset-state-function 旗標在 Wasm 函式庫的匯出介面中暴露一個重置函式，讓消費方應用可在函式庫 abort 後請求重置內部 Wasm 實例，而非整個應用崩潰。
原始來源：Cloudflare Blog — Making Rust Workers reliable、Wasm Exception Handling Spec
C++26 提案 P3951：meta::substitute 以反射實現編譯期字串插值
isocpp.org / Barry Revzin · 2026-04-22
Barry Revzin 在 BeCPP Symposium 分享了 P3951 提案，透過 C++26 的靜態反射能力實作編譯期字串插值，在格式化字串解析與轉換上超越 std::format 等既有方案。
技術背景：C++26 反射
C++26 靜態反射（P2996）允許在 consteval 上下文中以 std::meta::info 型別取得型別、函式、資料成員的編譯期元資訊，並透過 std::meta::substitute 在模板實例化時注入型別參數。P3951 將此機制應用到字串插值：格式字串在編譯期被解析為 AST 節點序列，每個 {...} 插值點對應一個 meta::info 描述，最終透過 meta::substitute 將節點序列實例化為具體型別呼叫，無需執行期解析。
提案示例：帶標記的插值
P3951 示範了超出單純值替換的能力——格式字串中可嵌入標記語法（如 {*10*} 表示強調），編譯期解析器可識別標記並生成對應的輸出轉換，整個過程不涉及執行期條件判斷：
consteval auto highlight_format = meta::substitute(
"x={} and y={*10*} and z={}!"_fmtstr,
types<int, int, std::string_view>
);與既有提案的對比
P3951 建立在 Vittorio Romeo 的 P1819r0（原始字串插值提案）與替代方案 P3412 之上。主要差異在於 P3951 要求格式字串必須是編譯期常數（consteval），這使完整的編譯期解析與型別安全驗證成為可能，代價是不能使用執行期動態字串。
Herb Sutter 談 C++26 定案：在競爭、安全與 AI 浪潮中的語言演進
isocpp.org / BeCPP Symposium 2026 · 2026-04-26
Herb Sutter 於 2026 年 BeCPP 研討會的主題演講中，總結 C++26 標準最終化的技術走向，並回應記憶體安全批評與 Rust/Carbon 競爭壓力。
C++26 最終化的核心特性
C++26 的 WG21 工作計畫已進入最終投票階段，預計 2026 年底正式發布。本版主要特性包含：靜態反射（P2996，允許編譯期存取型別與成員的元資訊）、合約程式設計（Contracts，P2900，前/後條件宣告）、std::execution（P2300，sender/receiver 非同步框架）、以及 std::inplace_vector（P0843）。Sutter 強調靜態反射是 C++26 中技術影響最深遠的特性，它不只是語言功能的添加，而是開啟了元程式設計的新模式（如 P3951 的 meta::substitute）。
記憶體安全回應
面對 NSA、CISA 等機構敦促轉向記憶體安全語言的壓力，Sutter 指出 C++ 社群的回應路線：std::span、std::string_view、bounds-checking 等工具已在既有程式碼中降低緩衝區溢出風險；C++26 合約可在除錯模式下插入前後條件驗證；Profile 機制（型別安全、邊界安全、生命週期安全的靜態分析輪廓）提供可漸進採納的安全層。他承認這些措施是漸進的，但強調 C++ 的廣大既有程式碼庫與效能需求使整體移植到 Rust 在大多數場景下不切實際。
AI 程式碼生成的衝擊
Sutter 注意到 AI 輔助程式設計對語言生態的影響是雙向的：LLM 傾向生成訓練資料中佔比高的語言（C++），但也更容易在缺乏上下文時產出包含 UB 的舊式慣用法。他認為 C++26 的現代化特性（特別是 Profiles 和反射）應當被納入 LLM 訓練資料以推動轉型。