本記事は、TechFeed Experts Night#30 〜 Rust / WebAssembly最前線のセッション書き起こし記事になります。イベントページのタイムテーブルから、その他のセッションに関する記事もお読み頂けますので、一度アクセスしてみてください。

本セッションの登壇者

セッション動画

では、「ざっと理解するRust 2024 Edition」ということで発表させていただきます。
matsu7874と申します。今は株式会社estieでソフトウェアエンジニアとして働いていて、普段からRustでWebアプリケーションを開発する仕事をしています。

今日はまずEditionとは何ぞやという説明をして、その後にRust 2024 Editionの変更点について、今、出ている情報に基づいてお話しします。

3年ぶりの新 Edition がリリース

まずEditionですが、今年2024 EditionがRust 1.82.0として10月にリリースされる予定です。これまではRustの2015、2018、2021と、3年に1回のペースでリリースされてきました。

Editionというのは、つまり破壊的変更が入るんですね。これまでコンパイルできていたものがコンパイルできなくなるような、文法上の仕様変更を入れたいけれど、前の文法で書かれているパッケージを全部書き換えるようなことはしたくない。そういうモチベーションでこのEditionという仕組みが導入されています。

したがって、新しい文法や新しいルールが使えるようになるんですが、これまでのEditionで書かれたクレートも新しいEditionで使うことができます。たとえば、[package]の下にedition=という項目で古い2015 Editionを指定すると、まだキーワード化されていなかった async や await などを引数名として使った 2015 Editionとして公開されているライブラリを、2021 Editionから呼び出して使うことができます。どのEditionも最新のコンパイラでコンパイルできることが保証されているので、メンテナンスコストをあまりかけずにどんどん新しい文法を使える仕組みになっています。

prelude への追加と unsafe 処理の使い方

では、Rust 2024 Editionの変更点についてお話しします。まず、 prelude に Future とIntoFuture が追加されます。これまで引数に IntoFuture などを使う場合は毎回 use 文を書いてやる必要があったんですが、よく使うので、明示的に書かなくても使えるように prelude に追加される予定です。

続いて、unsafe functionの中でのunsafeな処理に「unsafe block の中に入れてください」という警告が出るようになります。今までは unsafe fn に2つの意味がありました。人間のプログラマーがunsafe blockの中に入っている unsafe な処理の安全性を担保するという外部に対する表明と、その中でUnsafe 文が呼び出せるようになるというコンパイル向けの意味です。これに対して、明確にここだけunsafe処理を実行していることが分かるように、unsafe blockをunsafe fnの中に書くという議論がされています。

RPIT lifetime capture にも変更点がありますが、これは最後の@TaKo8Kiさんのトークを楽しみにしていてください。

意図しない公開やフィーチャー利用を防止

続いて、static mut への参照を禁止する変更が入ります。static mut は書き換えできるメモリ上に確保された定数みたいなもので、unsafe blockの中からは書き換えを行うことができますが、今後は unsafe block 内であっても static mut の参照が禁止されます。下のコード例のように static mut とグローバル定義してあるものがそうです。これまでは warn でしたが、もう完全にコンパイルが通らなくなります。ptr::addr_of_mut! マクロで生ポインタを触る形で解決してもらうのがいいだろうという議論がされています。

続いて「public/ private dependencies」という概念を足します。意図せず、別クレート由来の公開APIを公開してしまったり、内部実装の変更のつもりで公開APIを変更してしまったりということが発生していました。たとえばこの例のように、struct を定義する際に他のクレートからpublic な trait をderive すると、deriveしたものも暗黙に外に公開されます。これが、public = true を明確に付けるように変わります。これによってsemverの考え方をより自動的に扱えるようになります。

これも似た話で、Cargoから暗黙的なフィーチャーをなくす変更が入ります。具体的には、optional な dependencies に対して dep キーワードというものが必要になります。現状は、特定のフィーチャーをオンにした時だけ使いたい dependencies がある場合、optional = true と書けば、それが指定されている時だけコンパイルするように設定できます。次の例ではmyfeatというフィーチャーをオンにした時だけ sublib を読み込みたいのですが、dependencies のフィーチャー名には暗黙的にこのクレート名がそのまま使われているので、間違って myfeat でなく sublib と書いてしまうみたいなことが発生し得ます。

しかもこれは外部にも公開されてしまっていて、本来であれば myfeat と書いてほしいのに、中身の sublib を直接書くことができる状態になっています。

これに対して2024 Editionでは、sublib の前に dependencies を表す dep:を付けることで、これがフィーチャーではないということを明確にすることができます。外部から sublib や dep:sublib と指定しても動作しません。

スタイルの一部実装を修正

最後にスタイルの変更があります。rustfmt の標準設定で、最後の要素のぶら下がり規則が変わります。

これまでクロージャだけぶら下がっていましたが、それ以外のものもぶら下がるように変わります。

左側がこれまでのものです。クロージャだけが引数と開括弧までが元の式と同じ行の中に書かれていて、その引数が次の行に書かれているというような形です。一方、構造体などのブロックは括弧で改行されていました。本来同じに扱うようスタイルガイドに指定されていたものがうまく実装できていなかったので修正されます。賛否両論はあるようですが、同じに扱うのがデフォルトになるようです。

まとめです。より使いやすくなる、より安全になる、より明示的になる、とまとめられるかと思います。より安全になりますので、ぜひ2024 Editionを使っていければと思います。以上です。ありがとうございました。