Rust 1.100.0が公開、10年越しのnever typeが安定化。Cargoには「公開直後の版を拾わない」待ち時間設定も

まず初めに

バージョン番号が1.100に到達したこと自体は、ただの数字の区切りです。数字より中身です。10年かけて安定化できなかった型がようやく入り、それと同じリリースに「新しい依存は、しばらく寝かせてから取り込め」という供給網向けの実務機能が同居している。言語の理想と、現場の防衛が同じ箱に入った、Rustらしいリリースです。

※個人の感想です

never typeの安定化

Rust 1.100.0の中心は、never typeの安定化です。never typeは ! と書く「値が存在しない型」で、決して値に解決しない計算（発散する計算）を表します。return や break、std::process::exit のような制御フローを終わらせる式も、この型を持ちます。

これまでもnever typeは使うことができ、関数の戻り値の型として -> ! と書くことは可能でした。今回の安定化で、型が現れるあらゆる場所で名前を書けるようになります。あわせて、Infallibleはnever typeの別名（エイリアス）になり、従来Infallibleを使っていたAPIは ! と互換になりました。

公式ブログは、この安定化に10年と5回の失敗があったこと、そしてプロジェクトゴールとしての完了であることを明記しています。なお、Infallibleを別名化するために破壊的変更が1つ入っています。2024より前のエディション（2015／2018／2021）で「never typeフォールバック」が () から ! に変わります。影響はまれなケースに限るとされますが、到達不能コードの検出が増える場合がある、と同ブログは注意を促しています。事前にfuture compatibility警告が出されており、公開クレートへの修正も進められた、という説明です。

Allocator APIとDropGuard

Allocator APIの中核部分も安定化しました。ライブラリ作者がカスタムアロケータを定義し、現時点ではVecとBoxといった標準ライブラリの型と組み合わせて使えます。新たに安定化したAllocatorトレイトが土台で、「Allocators 1.0」プロジェクトゴールの基盤と位置づけられています。使える範囲の拡大は今後の課題として残っている、とブログは述べています。

DropGuard APIは、スコープを抜けるあらゆる経路でクロージャを実行する仕組みです。RustのDropは、通常の終了でも return でも ? でもパニックでも、変数がスコープを出る際に処理を実行できます。ただ「関数を抜けるときに無条件で何かしたい」だけの場合にDropの実装は大げさでした。新しく入った core::mem::DropGuard は、ドロップ時にクロージャを実行するヘルパー型です。

Cargo側の変更

Cargoでは「min-publish-age」を意識した依存解決が安定化しました。悪意のあるバージョンは、公開から数時間から数日以内に自動スキャナやコミュニティによって発見されることが多い、という前提に立ち、新しく公開されたバージョンを一定期間取り込まない設定ができるようになったものです。この運用は「dependency cooldowns（依存関係のクールダウン）」とも呼ばれます。.cargo/config.toml に [registry] global-min-publish-age = "3 days" のように書いて有効化します。

そのほか、Cargoが使われていない依存関係を報告するようになりました。ビルドを遅くする不要な依存や、特定プラットフォームでだけ必要な依存を洗い出すための機能で、従来のrustcのlintではCargoと組み合わせた場合に誤検出があった点を補うものです。Cargoのキャッシュ衝突の削減や、ゼロサイズ型を出現させる（conjuring）操作の安定化も含まれます。詳細は公式のリリースノートにまとめられています。

詳細はリリースノートへ

本記事で触れたのは主要な変更点のみで、安定化したAPIの全一覧や細かな言語仕様の変更は、公式のリリースノート（Rust Release Notes）にまとまっています。ゼロサイズ型を出現させる操作の安定化、Cargoのキャッシュ衝突の削減といった項目も、詳細はそちらで確認できます。

利用時の更新手順は従来どおりで、rustupでインストールしている場合は rustup update stable で1.100.0が入ります。ベータ版やnightly版での事前検証を担う仕組みも従来どおり用意されています。

IT Postの見方

IT Postでは、このリリースで実務への影響が一番大きいのは、実はnever typeではなくCargoのmin-publish-ageだと考えます。サプライチェーン攻撃の初動は「公開直後の悪意ある版を、誰かが検証する前に取り込む」ことで成立します。数日待つだけで、その窓のかなりの部分が閉じます。言語の新機能と違い、設定1つで今日から効く防御です。

一方でnever typeの安定化は、10年越しの宿題が片付いたという意味で象徴的です。IT Postでは先日、Ruby on Railsの脆弱性21件の記事（Railsの記事）でも触れましたが、言語とフレームワークの「地味な基礎工事」は、派手なAIの発表の陰で淡々と進んでいます。その積み重ねが、結局はエコシステム全体の事故率を下げていきます。

今後どうなりそうか

利用者側の当面の作業は、1.100.0への更新と、never typeフォールバックの変更で警告や到達不能コードの検出が増えていないかの確認です。あわせて、min-publish-ageを自社の .cargo/config.toml に入れるかどうかは、検討に値する論点です。待ち時間は利便性と引き換えですが、緊急のセキュリティ修正まで遅らせない運用設計とセットで考える必要があります。

Allocator APIは「基盤が入った」段階で、使えるコレクションや場面の拡大はこれからです。次のマイナーリリースでどこまで広がるかが、この機能の実用度を決めます。新たな事実が公表されれば、本記事を更新します。