6月3日、Elixir開発チームが「Elixir v1.20 released: now a gradually typed language」と題した記事を公開した。

Elixir v1.20は、型注釈を一切必要とせずに型推論と段階的型チェックを実行する画期的な型システムを導入し、Elixirを段階的型付け言語に進化させた。この型システムは既存のコードを変更することなく、実行時に必ず失敗する確実なバグ（verified bugs）を効率的に発見できる。

近年、TypeScriptやPython（type hints）、Go（generics）など、多くの言語が型安全性を強化している。動的言語として知られるElixirがついに型システムを導入したことは、関数型プログラミング言語の進化における重要な転換点となる。特に注目すべきは、従来の段階的型システムの課題を解決する独自のアプローチだ。

段階的型付けとは何か

段階的型付け（gradual typing）は、動的型付け言語に段階的に型チェック機能を追加する手法である。TypeScriptやPython（mypy）などが採用しているが、従来の実装には「型注釈が必要」「既存コードの大幅な修正が必要」といった課題があった。Elixirの新しいアプローチは、これらの問題を根本的に解決している。

従来の段階的型付けを超える「dynamic()」型の革新

Elixir v1.20の型システムで最も革新的なのが**dynamic()型の実装である。多くの段階的型システムが採用するany()型は「何でもあり」を意味し、型違反の報告を停止してしまうが、Elixirのdynamic()型は互換性（compatibility）と絞り込み（narrowing）**という2つの性質により、型情報を範囲として扱い段階的に絞り込む。

例えば、以下のコードを考えてみよう：

def percentage_or_error(value) when is_integer(value) do
  value_or_error =
    if value > 1 do
      value
    else
      "not well"
    end
  
  if value > 1 do
    value_or_error / 100
  else
    String.upcase(value_or_error)
  end
end

value_or_errorはinteger() or binary()型を持つが、従来の型システムでは/演算子とString.upcaseの型違反が報告される。しかしElixirの型システムはvalue_or_errorを**dynamic(integer() or binary())として扱い、受け入れ可能な型と供給される型が完全に分離している場合のみ**型違反を報告する。

上記の例では、/は数値を期待しdynamic(integer() or binary())はinteger()になり得るため分離していないので違反は報告されない。しかし以下の場合：

Map.fetch!(value_or_error, :some_key)

Map.fetch!はマップ構造を期待するが、value_or_errorは実行時に整数か文字列にしかなり得ない。この場合、型が完全に分離しているため型違反が報告される。

高度な型推論とガード文の活用

Elixir v1.20ではガード文での複雑な型推論も実装されている。Elixirのガード文は関数の実行条件を指定する機能だが、新しい型システムではis_map_key/2やtuple_size/1などのガード関数により、関数本体内での型を正確に追跡する：

def example(x) when is_map_key(x, :foo)
  # xは%{..., foo: dynamic()}として推論される
  
def example(x) when not is_map_key(x, :foo)
  # xは%{..., foo: not_set()}として推論され
  # x.fooへのアクセスは型違反として報告される

タプルサイズの検査も正確に追跡される：

def example(x) when tuple_size(x) < 3
  # xは最大2要素のタプルとして追跡され
  # elem(x, 3)へのアクセスは型違反として報告される

条件分岐での型の絞り込み

case文や条件分岐では、前の節の情報を使って後続の節の型を絞り込む：

case System.get_env("SOME_VAR") do
  nil -> :not_found
  value -> {:ok, String.upcase(value)}
end

System.get_env/1はnilまたはbinary()を返すため、最初の節でnilにマッチした結果、2番目の節でvalueがbinary()のみであることを認識し、String.upcase(value)は型違反なしで通る。

開発背景と性能向上

この型システムは2022年から開発が始まり、CNRSとRemoteの提携により実現した。現在はFreshaとTidewaveがスポンサーとして開発を支援している。

Elixir v1.20では型システムに加えコンパイル時間も大幅に改善された。特に多コア環境での性能向上が顕著で、合成ベンチマークではElixirのビルドツールがBEAM言語の中で最速となった。新しいコンパイラオプション:module_definitionにより、大規模プロジェクトでのコンパイル時間をさらに短縮できる。

今後の展望：型シグネチャへの道筋

現在の実装は型推論のみだが、将来的には集合論的型を活用した新しい型シグネチャの導入が検討されている。ただし、以下の条件をクリアする必要がある：

• Elixir v1.20での型システム性能の検証
• 再帰型の効率的な実装
• パラメトリック型の効率的な実装
• マップのキー・値ペアの列挙可能な実装

これらの問題が解決され次第、型付き構造体定義と型シグネチャの検討が始まる予定だ。

Elixir型システムが業界に与える影響

Elixirの新しいアプローチは、「型安全性」と「開発者の生産性」という従来のトレードオフを解決する可能性を秘めている。型注釈不要で既存コードがそのまま動作し、かつ「確実なバグ」を発見できるという特徴は、他の言語設計にも大きな影響を与えるだろう。

特にOTP（Open Telecom Platform）による高い耐障害性で知られるElixir/Erlangエコシステムに型安全性が加わることで、よりミッションクリティカルなシステム開発での採用が加速すると予想される。

詳細はElixir v1.20 released: now a gradually typed languageを参照していただきたい。