出来事の日付：2026年6月3日。 Elixir 1.20はすべてのプログラムを対象とする段階的型検査を導入し、2022年に研究活動として始まったプロジェクトの最初の開発マイルストーンを完了した。このリリースでは、開発者が型アノテーションを追加しなくても推論が行われるため、既存コードの到達不能な経路や型違反を検査できる。

保守担当者は、こうした違反を、スタイルや発生可能性に基づく警告とは区別している。彼らが掲げる目標は、実行された場合にランタイムで必ず失敗する操作を報告しつつ、偽陽性を極めて少なく抑えることだ。このシステムは、和集合、共通部分、否定から構成される集合論的型に基づいており、この手法は2023年に発表された研究論文で説明されている。

中心的な機能は、Elixirの`dynamic()`型である。多くの段階的型システムでは、すべての操作が許可されるため、`any`型が有用な検査を事実上停止させることがある。これに対しElixirは、動的な値を、プログラム内を移動するにつれて絞り込める実行時の可能性の範囲として扱う。推論された可能性と、ある操作が受け入れる入力との間に重なりがない場合、警告が生成される。

例えば、ある値が整数またはバイナリのいずれかにしかなり得ない場合、数値を受け入れる操作でその値を使用しても、整数の場合は有効なままなので、直ちに違反とはならない。同じ値をマップを必要とする関数に渡すと、どちらの可能性とも重ならないため、チェッカーはそれを指摘できる。この互換性ルールは、明確なエラーを発見しながら、有効な動的コードを維持することを目的としている。

絞り込みによって、さらに精度が高まる。コードがフィールドにアクセスして数値演算を適用すると、チェッカーは当初は動的だった入力を、特定の数値キーを持つマップへと絞り込める。その後、そのマップ自体を数値として使おうとすると、無効だと特定できる。また、このシステムはガード、タプルのサイズテスト、マップのキー、リスト構造からも情報を推論する。

Elixirは、「If T」型絞り込みベンチマークの13カテゴリー中12カテゴリーに合格したと報告した。この結果はプロジェクト側が提供したもので、それ自体があらゆるコードベースでの性能を示すわけではないが、アノテーションのないプログラムから有用な型情報を復元するという意図を表している。

ユーザーが記述する型アノテーションは、後の段階で導入される予定だ。それまでは、バージョン1.20は移行作業をほとんど必要とせずに安全性に関するシグナルを抽出することに重点を置く。この取り組みは、フランスのCNRSおよびRemoteとの提携から発展したもので、現在はFreshaとTidewaveが開発を支援している。したがって、このリリースはコンパイラ解析を直ちに変更する一方、言語の明示的な静的型付け機能は将来のマイルストーンに委ねている。

アノテーションより先に推論を採用することで、保守担当者はソースコードの変更を強制せずに、実際のプロジェクトでチェッカーの挙動を観察することもできる。開発者は診断が理解しやすく実行可能かどうかを評価でき、ライブラリ作者は動的な呼び出しパターンとの互換性を維持できる。この期間に得られたフィードバックは、その後のアノテーション設計を形作り、チームがより厳格な境界をどのように導入するかを決める材料となり得る。