Swiftの新機能

Swiftの新機能

Swiftの新機能を確認しましょう。Parameter packやマクロなどの機能でさらに拡張可能性が高まり表現豊かになったAPIについて学びましょう。また相互運用性の改善点や、Foundationからサーバでの大規模配信プログラムにいたる各所で改善された、Swiftのパフォーマンスや安全面での利点について解説します。

関連する章
- 0:39 - Swift project update
- 2:44 - Using if/else and switch statements as expressions
- 3:52 - Result builders
- 4:53 - type parameter packs
- 9:34 - Swift macros
- 19:47 - Swift foundation
- 23:25 - Ownership
- 27:59 - C++ interoperability
- 32:41 - What's new in Swift Concurrency
- 38:20 - FoundationDB: A case study
リソース
関連ビデオ

WWDC23
WWDC21
- Swiftの並行処理: 舞台裏
ダウンロード

♪ ♪
こんにちは What's New in Swift 5.9へようこそ私はBenです　同僚のDougと Swift言語の改善点についてお話ししますまた、Swiftのclean syntaxを使って実装を簡略化する方法やフレームワークデベロッパが新しいAPIsをより自然に使えるための非常にパワフルな機能についても紹介しますさらにLow Levelのコードにおいてパフォーマンスと安全性を制御する新しい方法についてお話ししますまずはSwift オープンソースプロジェクトのお話からですこれはコミュニティーのみなさんによる素晴らしいアップデートでコントリビューターやSwiftユーザーなしにはできなかったことです swift.orgに集まりこの言語を進展させ新しいイニシアチブを支持してくれたおかげで実現しています Swiftは言語の進化においてオープンプロセスを追求しています新機能や大きな動作変化は Swift フォーラムでオープンに提案されレビューされますこれらの言語提案はすべてウェブサイトのダッシュボードでご覧いただけます 1年前Swift Projectの管理で大きな再構築がありました Language Steering Groupの編成が発表され Swift言語とライブラリ８点についての主要な責任を担うことになりましたそれ以来このグループは 40の新言語提案を管理しそのいくつかを今日取り上げます
しかしまれに個別の言語提案が一つに統合されより大きなテーマとなります Swift concurrencyの追加は 10の提案で別々に紹介されたものですこのような場合のために Language Steering Groupはこれらの提案を結ぶ新しい方法を導入しましたそれがvision documentsですそのドキュメントは言語の大きめな変化の提案を構成しますこのグループが最初に受諾したのが Swift 5.9の新機能である Swift macrosのvisionでしたこの後でお話ししますもちろん言語の発展は Swiftコミュニティの役割の一部にすぎません言語の成功にはそれ以上のことが必要です素晴らしいツールや多くのプラットフォームのサポート豊富な資料などが挙げられますそれらの発展のため language steering groupと並行して ecosystem steering groupを設立しましたこの新機構についてはSwift.orgのブログポストに掲載されていますこの新グループの編成についてさらなる発表を今後予定していますでは今年度の Swiftのアップデートからはじめましょうまずコードでの表現を向上させる方法からです Swift 5.9には最もリクエストのあった言語拡張が含まれています if/elseとswitch文を式として認めることでコードを整理することができます
例えば複雑な状況において let変数を初期化したい場合このように読みにくい複合三項式に頼る必要があります
式であれば、より親しみがあり読みやすい if文を使えることになります
これはまたグローバル変数や格納型プロパティの初期化に役立ちます 1つの式ならいいものの条件が必要なら直ちに実行するためにはクロージャを使用せねばなりません
しかしif文が式となるなら余計なものを省けてコードがスッキリします Result buildersやSwiftUIのような機能を動かす宣言型のsyntaxは今年著しい発展が見られます型検査やコード補完の最適化やエラーメッセージの改善です
この改善は特にInvalidなコードに焦点を当てていますエラーのあるResult Builderコードは型チェッカーがあらゆるパスを探るためフェイルが返るまで時間がかかりました
Swift 5.8でInvalidコードの型チェックは速くなり Invalidコードのエラーメッセージはより正確になりましたこれまでInvalidコードによってはまったく違う箇所の紛らわしいエラーが返されることがありました Swift 5.7ではこのようなエラーが返りますが実際の間違いはここにあります
最新リリースではより正確なコンパイラ診断で問題を確認できます次にジェネリックシステムの追加で毎日使用するフレームワークが大きく改善されます
Swiftで書く場合たいていジェネリクスを使っています型推論は高度な機能を理解する必要なくこれらの型を使用可能にします例えば標準ライブラリの配列型はジェネリクスで保存したいどのタイプのデータにも対応する配列を提供します配列を使うときに必要なのは要素だけです要素型の引数を特定する必要はありませんこれは要素値から検出できるからです
Swiftのジェネリックシステムは natural APIsを可能にし型情報を保存しますそのため　あなたのコードは指定した明確な型でスムーズに動作しますこれはSwiftコンパイラのコードベースからの例ですこのAPIは強く型付けされた値を定義するために要求される型を評価しますつまりブール値をリクエストでき、ブールの結果を得られるのです
APIによっては明確な型だけでなく幾つもの引数を抽出しようとするものもありますですので関数は1つのリクエストに 1つの結果 2つのリクエストに2つの結果 3つのリクエストに3つの結果を返します
そのためジェネリックシステムは幾つもの関数を扱えるメカニズムと一緒に使用されることによってすべての型に対してそれに相対する型を結びつけるのです Swift 5.9以前はこのパターンの成立にそれぞれの引数に対して APIがサポートするオーバーロードを追加しなければなりませんでしたしかしそれには制限があります定義する引数の数に意図的な上限が設定されてしまうため数が多すぎるとコンパイルエラーとなりますこの場合 7つの引数がありますが 6つ以上対応できるオーバーロードがありませんこのオーバーロードパターンと制限は概念的に任意引数を扱う API全体に見られます
Swift 5.9でジェネリックシステムは引数のジェネリック抽象化を可能にしこのAPIパターンに対するすばらしいサポートが追加されますこれは一緒にパックされた幾つもの個別型パラメータを表現する新しい言語コンセプトで可能になりますこの新しいコンセプトをタイプパラメータパックと呼びますパラメータパックを使い現在固定引数に対しオーバーロードがそれぞれあるAPIは 1つの関数に含められます
1つのリクエストの結果型を意味する Resultを受け入れる代わりそれぞれの結果型に対する個別のリクエストを受け入れられるのです関数は括弧内に1つの値か各値を含んだタプルで各結果インスタンスを戻しますこれで上限なくすべての引数に対応することができます
型推論はパラメータパックの使用に気付かぬまま APIを自然に使用できます
限りなく引数に対応できる evaluate functionを呼び出すのは固定長オーバーロードを呼び出すようなものです Swiftは関数の呼び方に基づきそれぞれの引数の型と合計数を検出しますジェネリックライブラリAPIについては「Generalize APIs using parameter packs」をご視聴くださいジェネリックAPIを自然に呼び出すのは簡潔なコードによる明確な式という Swiftの基本デザインゴールです
Swiftの高度な言語機能により目的を簡単に伝える美しいAPIが可能になります
これらの高度な言語機能による恩恵を Swiftで書く一行目から受けられます配列や辞書型などジェネリクスであれ SwiftUIでのデザインでもです Swiftは段階的な開示を取り入れており用意ができればより高度な機能を学べるようになっています
Swift 5.9はマクロシステムを用いてライブラリ作者に表現豊かなAPIデザインの新しいツールボックスを提供しさらにパワーアップさせましたではDougがお話ししますマクロで言語自体の可能性を広げられボイラープレートを取り除き Swiftの表現豊かなパワーを引き出しますでは条件がtrueかチェックするときによく使われるアサート関数を見てみましょうアサートはfalseの場合プログラムを停止しますしかしその場合ファイルとラインナンバーしか表示されませんロギングやデバッガを使わねばより詳細な情報を得られませんこれを向上させる試みはありました XCTestはassert-equal作業で 2つの値を別々にとらえるため少なくとも2つの違う値を確認することができますしかしどちらの値が間違いかわかりません違うのはaかbかそれともmaxの結果かこの方法はアサートでのすべてのチェックに向いていません最初のアサーションを見ると失敗した時にログにあるべきソースコードの情報がたくさんあります何のコードか？ aとbとcの値は？ maxは何か？カスタム機能なしではこれは向上できませんでしたでもマクロで可能になります
この例では#assert構文で assertというマクロが拡張されます見覚えがあるかもしれないのは Swiftには既にこれと同じスペルのものがあるからです #fileや#selectorや#warningがその例ですアサートマクロは関数版とよく似ていますがマクロであるためアサーションがフェイルするとよりリッチな体験ができますアサーションに失敗したコードが示されその結果になった各値も示されています
Swiftではマクロは型や関数のようなAPIなのでそれを定義するモジュールをインポートしてアクセスします他のAPI同様マクロはパッケージとして配給されますこのアサートマクロはGitHubにあるオープンソースSwiftパッケージの PowerAssertライブラリからのものです
マクロパッケージの内部を見るとアサートのマクロ宣言があります macroのキーワードが付いていますがそれ以外は関数とよく似ています条件をチェックする無ラベルのブールパラメータがありますこのマクロが値を提示すればその結果型は従来のArrow Syntaxで書かれますマクロの使用はパラメータに対し型チェックされますつまり最大値を比べるのを忘れるというようなマクロ使用上での間違いを犯した場合便利なエラーメッセージがマクロの拡張前に表示されます Swiftでのマクロの使用は非常に素晴らしいデベロップメント体験を提供しますこれはマクロはよくある入力で作動し意外性なくプログラムの拡張コードを作成するためですたいていのマクロは externalMacroと定義され文字列でマクロ実行のモジュールと型を明示します externalMacro型はコンパイラプラグインとして振る舞う別のプログラムで定義されます Swiftコンパイラはマクロ使用のソースコードをプラグインにパスしますプラグインは新しいソースコードを作り Swiftプログラムに再び統合されますここではマクロがアサーションをコードに拡張しそこで個々の値をとらえソースコードに表示していますマクロがあなたのためにボイラープレートを書いてくれますマクロ宣言にはもう一つの情報があります　ロールですこのアサートマクロは freestanding expressionマクロです #構文を使用するため freestandingと呼ばれ新コードを作るためにその構文上で作動します値を作り出す場所ならどこでも使用できるので expressionマクロです Foundation Predicate APIは expressionマクロのいい例を提供します Predicateマクロはクロージャでタイプセーフに predicatesを書くことができますその結果のpredicate値は Swiftコレクション作業の SwiftUIやSwiftDataなど他のAPIで使用できますマクロ自体は入力型セットにおいてジェネリックです入力型値で作動する関数で入力セットがマッチするかブール結果を算出するクロージャ引数を受け入れますそしてマクロはプログラム内で使用できるPredicate型のインスタンスを戻します
しかしマクロにはさらに奥がありますボイラープレートを書くのは以前書いたコードをそこから引き出したものと拡張する必要があるからです例を見てみましょう私はコード内でenumをよく使っています相対及び絶対パスをとらえるこの列挙型パスががそうですしかし特定のものをチェックすることがよくありますコレクションから絶対パスをフィルターする場合などですもちろんisAbsoluteチェックを計算型プロパティとして書けますしかしいずれ別のものを書かねばならなくなるでしょうこれは面倒な作業になります
そこでマクロにボイラープレートを作成させることができます Case detectionはattachedマクロで property wrappersのようなカスタム属性構文で書かれています Attachedマクロはこの列挙型宣言のように宣言構文の入力として受け止めコードを作成します
このマクロ拡張コードは通常のSwiftコードでコンパイラがプログラムに統合させますマクロが作成したコードを点検してデバッグしさらにカスタム化したいならコピーすることもできます
Attachedマクロには属する宣言をどう拡張するかに基づき 5つのロールがあります今話したcase detectionマクロは member attachedマクロで型や拡張に新しいmembersを作成します Peerマクロは属する宣言と共に新しい宣言を追加します非同期メソッドのcompletionHandler版を作ったりするのがその例です
Accessorマクロは格納型プロパティを計算型プロパティにします特定のプロパティアクセスの実行や property wrappersより柔軟な方法でストレージを抽象化するのですまたattachedマクロは特定のメンバーに属性及びプロトコルconformanceを追加します Attachedマクロロールの幾つかは役にたつ効果を作るために一緒に構成することもできますその重要な例の一つがobservationです Observationは常にSwiftUIの一部でしたクラスのプロパティの変化を監視するには型をObservableObjectとしてすべてのプロパティを@Publishedとし ViewでObservedObject property wrapperを使用しますステップが多いため1つでも見逃すとインターフェイスは更新されませんマクロを使ったObservationで改善ができます
Observableマクロをクラスに付けすべてのプロパティに Observationが提供されますプロパティ毎にアノテーションをつける必要はなくマクロがすべて手配するため何の心配もする必要がなくなります
Observableマクロは 3つのマクロロール構成を処理しますそれらのロールがどう働くのか見てみましょう各マクロロールはPersonクラスが Observableマクロに拡張されるよう特定の対応を行いますメンバーロールが新しいプロパティとメソッドを導入します
メンバー属性ロールが監視クラスの格納型プロパティに @ObservationTrackedマクロを足しますそしてgettersとsettersに拡張し observation eventsを起こします最後に適合ロールが Observableプロトコルに適合を導入します
多くのコードに見えますがすべて普通のSwiftコードで Observableマクロの後ろに折り込まれているのです
プログラムへの影響を理解するためどうマクロが拡張しているか見る必要があればいつでもXcodeで確認できます
を実行しエディタでマクロ拡張ソースコードを確認できますマクロ作成コード内のエラーメッセージは自動的に拡張コードを表示しデバッガでコードに出入りすることができます
Swiftマクロはより表現豊かなAPIを実現しボイラープレートを除く新ツールを提供し Swiftの表現力の可能性を開きますマクロは入力を型チェックし普通のSwiftコードを作成しコードの設定された場所で統合させるためその効果は簡単に納得がいきますマクロの動作を理解したければいつでも拡張ソースコードをエディタで確認できますこれは表面的なことに過ぎません「Expand on Swift macros」では Swiftマクロのデザインについてすべての質問にお答えできるように説明していますそして「Write Swift macros」で独自のマクロ開発をすることが可能ですみなさんがどのようなマクロを作るか楽しみです
当初からSwiftは拡張性のある言語としてデザインされました Swiftのデザインは堅苦しくなく読み書きしやすい明白で簡明なコードの表現性に重点を置いていますジェネリクスやネイティブコンカレンシーサポートなど Swiftのパワフルな機能を行使することで SwiftUIやSwiftDataのようなフレームワークは素早く　求める結果を得られ大切なことに焦点を当てる時間を提供します
しかし高度な機能に関わらず Swiftはまた効率的ですネイティブにコンパイルしガレージコレクションではなく値型と参照型を使用するため小さいメモリフットプリントを達成できます
この拡張性によりこれまでObjective-Cで可能だった場所だけではなく CやC++を使わねばならない低レベルのシステムでも Swiftを使用できるということですつまりより多くの場所で Swiftの明白なコードと安全性の担保を活用することができますつい最近FoundationフレームワークのリライトをオープンソースにしましたこれによりApple及びそのほかのプラットフォームで一つのFoundationを共有履行できることになりますまたSwiftで大量のObjective-Cと Cコードをリライトすることになります macOS SonomaとiOS 17では DateやCalenderのようなessential typeや LocaleやAttributedStringのようなフォーマットと国際化のエッセンシャルまたJSONエンコードやデコードが Swiftに新しく実装されていますそしてパフォーマンスも向上しています
Calendarが重要な日を計算する能力は中間アロケーションを避けるため Swiftのvalue semanticsを使用して 20%以上のスピード向上を達成しています FormatStyleを使った日付のフォーマットも標準日時のテンプレートのフォーマットベンチマークで 150%ものスピード向上を達成していますさらに新パッケージでは JSONデコードにも向上が見られます Foundationには新しく JSONデコーダとJSONEエンコーダを導入し Objective-Cコレクション型への非効率なラウンドトリップを取り除くことができます Codableの初期化において JSONのパースをSwiftに統合することもパフォーマンス向上につながりますテストデータのパースのベンチマークでは 2~5倍のスピード改善が見られていますこれらの改善は古いObjective-Cから Swiftへの履行によるブリッジの減少と新しいSwift基盤の実行の速さによるものです
それではベンチマークの一つを例に見てみます Venturaではブリッジを要するため enumerateDatesを呼ぶのは Objective-CがSwiftより少し速かったのですが MacOS Sonomaでは同じ関数を呼ぶのに Swiftの方が20%速くなっていますブリッジを省いたこともありますが新しい関数実行自体が Objective-Cから呼ぶより速くなったためですこの日付計算は特に複雑ではないため 2つの言語間におけるオーバーヘッドの削減がよくわかるかと思いますしかし低レベルのシステムを使用している時必要な性能を得るためにきめ細かい管理が必要になる時があります Swift 5.9ではそのような管理を可能にするため新しいオプトイン機能を追加していますこれらの性能はオーナーシップに焦点を当てますつまりアプリをパスする上でコードのどの箇所が値を持つかということです
これらの機能をいつ使うべきかコードの例を見てみましょう低レベルのシステムコールに Swiftインターフェイスを与えるファイル記述子のためのシンプルなwrapperがありますしかしこのAPIではまだ簡単にミスしてしまいます例えばcloseしてからファイルに書いてしまうかもしれません型がスコープから出る前にcloseメソッドで常に手動でクローズする必要がありますでなければリソースリークになります解決策の一つは型がスコープから出る時に自動的にクローズするdeinitをもつクラスにすることです
しかしこれには欠点があります通常は問題ありませんがさらなるメモリーアロケーションが必要なためシステムに限りがある場合は問題になります
またクラスには参照セマンティクスがあります故意なくスレッドを通してファイル記述子型を共有してしまい競合状態や期待しない保持につながるかもしれません
しかし少し戻って構造体を見てみましょう
この構造体も参照型のように作用しています真の値を参照するintegerを保持していますつまりオープンファイルですこの型をコピーするとバグをもたらす可能性がありますミュータブルステートをアプリ中で共有する可能性がありますこの構造体のコピーを作る可能性を防ぐ必要があります
Swift型は構造体であれクラスであれ既定上ではコピー可能です通常なら正しい選択です過度で不必要なコピーはコードのネックになりますがコンパイラがコピーに関し明確にするよう常にうるさく言われるよりはときどき、Instruments でネックを探す方が楽ですしかしそのようなコピーが問題になる場合もあります値のコピーが正当性の問題につながる時などですファイル記述子wrapperがその例です Swift 5.9では structとenum宣言に適用できる新しい構文があり型をコピーする暗黙的な機能を抑えることができます型がコピーできなくなるとクラスの時と同様に deinitを与えて型値がスコープ外に出た時に作動します
コピーできない型はクローズを呼ぶ問題の解決にも使用できまた、その時は他のメソッドも使えます
クローズオペレーションは consumingとも明記できます consumingメソッドや引数は呼び出したメソッドの値のオーナーシップを放棄しますこの型はコピーできないのでオーナーシップを放棄すると値を使用できなくなります
既定上 Swiftのメソッドはselfを含むこれらの引数を借りることになりますつまりファイル記述子を借りる writeメソッドを呼びバッファーに書き出しその後値のオーナーシップがcallerに戻り closeのような別メソッドを呼べるのです
しかしcloseは borrowingのデフォルトではなく consumingと明示されているので最後の使用となります
つまり先にファイルをクローズし writeのような別のメソッドを呼ぶとランタイムエラーではなくコンパイル時にエラーメッセージを受け取りますまたコンパイラはconsumingされた場所を指摘します
Non-copyable型はSwiftにおけるシステムレベル・プログラミングの新機能ですまだ進化が始まったばかりですが後のSwiftリリースでジェネリックコードに拡張する予定ですもしこの検討に興味があれば Swift forumsで活発に議論されています Swiftの成功の鍵は Objective-Cとの共存機能です当初からデベロッパは既存のコードベースにファイルやモジュール毎に Swiftを徐々に取り入れてきましたしかしObjective-Cで書かれたコードだけでないのも確かです C++で実装されたコアビジネスロジックを持つアプリも多くありそのインターフェイスは非常に困難でしたしばしSwiftからObjective-CへそこからC++へ行き逆戻るという余分な手動ブリッジレイヤーを足さなければなりませんでした Swift 5.9ではC++型と関数に直接Swiftからインタラクトする機能を導入します C++インターオペラビリティは Objective-Cインターオペラビリティと同様 C++ APIを Swiftの同等のものにマッピングし Swiftコードで直接使えるようにします C++は大きな言語でクラスやメソッドやコンテナなど独自の観念を備え持っています Swiftコンパイラは共通のC++イディオムを理解し多くの型は直接使用できます例えばこのPerson型はC++値型にある 5つの特殊メンバー関数を定義しますコピー及びムーブ・コンストラクタ代入演算子とデストラクタです Swiftコンパイラは値型として扱い適時に適切な特殊メンバー関数を自動的に呼び出しますさらにベクターやマップなど C++コンテナはSwiftコレクションとしてアクセス可能です
これらの結果 C++関数と型を直接使用した簡単なSwiftコードが書けるということです Personインスタンスのベクターでフィルタをかけ C++メンバー関数を呼びデータメンバーに直接アクセスできます
また逆に C++からSwiftコードを使用するのは Objective-Cと同じメカニズムです Swiftコンパイラが Swift API上にC++ビューを含む generated headerを作成しますしかしObjective-Cとは違い objc attribute注釈付きの Swiftクラスだけを使用するという制限はありません C++はプロパティやメソッドイニシャライザなどブリッジのオーバーヘッドなくしてたいていのSwift型とフルAPIを直接使用できますこれはC++がPoint構造体を使用している例です generated headerを含んだあと C++はSwiftイニシャライザで Pointインスタンスを作成し mutating methodsを起動し格納及び計算型プロパティにアクセスできます Swiftコード自身に変更はありません
SwiftのC++共存機能で Swiftを既存の C++コードベースと統合させるのが簡単です多くのC++イディオムが直接Swift内で表現できますたいてい自動ですが時として求めるセマンティックを指摘するアノテーションが必要になります Swift APIはC++から直接アクセスできアノテーションもコード変更も必要なく CやC++及びObjective-Cを使用するコードベースを通して Swiftを徐々に採用することが可能になったのです
C++共存機能は C++共存機能ワークグループがガイドを務める現在進展中のトピックです詳しくは「Mix Swift and C++」をご覧になるか Swift forumsにご参加ください
言語レベルでの共存機能は非常に大切ですがコードを作成できることも大切です Swiftを始めるために既存のXcodビルドシステムや Swift Package Managerを取り替えることは大量のコードを書き直すのと同様に大きなバリアですそこでCMakeと共に CMakeサポートを向上させました Swiftを言語の一つに宣言しファイルをターゲットに置き SwiftコードをCMakeビルドに統合できます
さらに重要なのはC++とSwiftを 1つのターゲット内にミックスでき CMakeはそれぞれ別々にコンパイルし両言語においてサポートするすべての適切なライブラリとランタイムをリンクしますつまりファイルやターゲット毎にクラスプラットフォームC++プロジェクトを今日からSwiftにて適用することができるということですまたbridgingやgenerated headersなど SwiftとC++/Swiftの混合ターゲットを含む CMakeプロジェクトのサンプルリポジトリを提供し取り掛かりやすくしています
数年前 async/awaitと structured concurrencyと Actorsのビルディングブロックに基づく新しいconcurrencyモデルを Swiftに登場させました Swiftのconcurrencyモデルは abstractモデルで違う環境やライブラリに適用できます Abstractモデルには TasksとActorsがあります Tasksは概念的にどこでも動作する連続的処理単位を意味します Tasksはプログラムに awaitがあると停止させられ処理可能になれば続行します
Actorsは同期メカニズムで孤立状態に相互排他的アクセスを提供します外部からActorに入るには処理を中断するため awaitが必要になります
TasksとActorsは abstract言語モデルに統合されておりそのモデル内で違う環境に対応するため違う形で実行されます Tasksはglobal concurrent poolで実行されます global concurrent poolは環境次第で処理スケジュールを決定します Appleのプラットフォームではディスパッチライブラリがシステム全体に最適化されたスケジュールを提供しプラットフォーム毎に広範囲に適合されていますより制限のある環境ではマルチスレッドスケジューラのオーバーヘッドは容認されませんその場合 Swiftのconcurrencyモデルはシングルスレッドcooperative queueで履行されます Abstractモデルは多様なランタイム環境に対応できる柔軟性があるため同じSwiftコードが両環境で作動します
さらにコールバック基盤ライブラリの共存機能が Swiftのasync/awaitサポートに当初から備わっています withCheckedContinuation演算でタスクを停止できコールバックに応答してのちに処理を続行できますこれでタスクを処理する既存ライブラリとの統合が可能になります
Swift concurrencyランタイムでの Actorsの標準実行は actorの実行への Tasksのロックフリーキューですが可能なのはそれだけではありません制限された環境ではatomicsがなくスピンロックのような別のconcurrency premitiveを使うかもしれませんその環境がシングルスレッドなら同期化は必要ありませんが actorモデルはプログラムにおいて abstract concurrencyモデルをそれに関わらず維持しますまだ同じコードをマルチスレッドの別の環境に持ち込めます Swift 5.9では custom actor executorsが特定のactorに独自の同期メカニズムの履行を許可しますこれによりactorsはより適応性が増し存環境に順応的になります例を見てみましょうここにデータベースコネクションを処理する actorがあります Swiftはこのactorのストレージに相互排他的アクセスを許しデータベースへの同時アクセスはありませんしかし同期化がなされる特定方法の制御がさらに必要ならどうでしょう？ actorsがない別のコードとキューを共有するためデータベースコネクションに特定のdispatch queueを使用するなら custom actor executorsで可能です
ここでactorに serial dispatch queueとそのdispatch queueに対応する executorを作り出す unowned executor propertyの実行を追加しましたこの変更によりactorインスタンスのすべての同期化はそのキューを通して起こります
actor外からpruneOldEntriesのコールを awaitするとそれに対応するキューで dispatch-asyncが実行されますこれでactorsによる同期化の提供を制御でき Objective-CかC++で書かれているためまだactorsを使用していない別のコードとactorの同期化も可能です
dispatch queuesによるactorsの同期化は dispatch queueがSerialExecutor プロトコルに従うため可能です actorsを使うため独自の同期化メカニズムを使うこともこのプロトコルに従う新しいタイプを定義して可能ですこれのコア演算は限られています Executorにおいて既にコードが実行されているかのチェックです例えばメインスレッドで実行してるのか？
過剰な参照カウントトラフィックなしで非所有リファレンスを executorに引き出しアクセスを許していますそしてコア演算のenqueueが executor Jobの所有権を取ります Jobはexecutorで同期的に実行されねばならない非同期タスクです enqueueが呼ばれた時点で serial executorで他のコードが実行されていない時に jobを実行するのが executorの責任になります例えばdispatch queueのenqueueがそのqueueでdispatch asyncを呼んでいます
Swift Concurrencyが使用し始められて数年になり tasksとactorsからなる抽象モデルは concurrent programming tasksの広範囲をカバーしています抽象モデル自体が適応性があり iPhoneやApple Watch サーバーに至るまで様々な処理環境に適応が可能ですまた重要箇所でカスタマイズできまだSwift Concurrencyに適応されていないコードとも相互運用が可能になります詳細は「Behind the Scenes」と「Beyond the basics of Structured Concurrency」をご覧ください最後にSwiftがiOSやmacOSなど見慣れた環境以外の非常に異なった環境で作動する事例研究を見てみましょう FoundationDBは分散データベースでコモディティハードウェアを運用し macOSやLinuxにWindowsなど様々なプラットフォームをサポートする大型のキーバリューストアにスケーラブルなソリューションを提供します FoundationDBはC++の大型コードベースオープンソース・プロジェクトですコードは主に非同期式でテスト目的で極めて重要な確定的シミュレーション環境を提供するactorsとランタイムを供給する独自の方法を備えていますコードベースの現代化を模索していた FoundationDBはその性能と安全性やコードの明瞭性から Swiftが最適であると決めましたすべてをリライトするのは大掛かりで危険な試みですその代わりにSwiftの共存機能を利用して既存のコードベースに統合させたのですこれはFoundationDBのmaster data actorの C++のインプリメンテーションの一部です
非常に複雑ですし C++をすべて理解する必要はありませんしかしコードの重要な部分をお見せしますまずC++にはasync/awaitがないため FoundationDBにはエミュレートにプレプロセッサのようなアプローチがあります
多くのC++コードベースのように非同期タスクの管理に独自のC++ Future型を実行していましたリクエストへのレスポンスを送る 2つの明白なメッセージがここにあります関数からの戻りに対する返答の慎重なペアリングに注目してください最後にFoundationDBにはメモリーを自動管理する独自の参照カウンタースマートポインタがあります Swiftではこれらすべてをもっと手際良く実行できます
（安堵の息）良くなりましたね Swiftではこの関数をasync関数として直接実行できますこのリクエストへの答えを提供するための普通のreturn型とreturn文があり同期しないことはありませんほかのSwift非同期コードと同様停止ポイントを示すawaitがありますこのSwift コードは継続を使って適応している C++ Future型と同調しています
ここには多くのC++型があります C++のMasterData型は参照カウンタースマートポインタを使用しています C++で肩に注釈をつけることで Swiftコンパイラはほかのクラス同様にこの型を使い自動的に参照カウントを管理します
requestやreply型などのほかの型は Swiftで直接使われるC++値型ですそして相互運用性は逆でも同じですこの非同期関数や Swift Concurrencyモデルにより紹介されたすべての作業は FoundationDBの既存の確定的ランタイムで作動しますそのため段階的な採用により既存のC++と調和し必要な箇所でSwiftの恩恵を受けることができるのです
ここではいろんなトピックをカバーしましたより表現的なAPIを可能にしよりよいコードを素早く書けるパラメータパックやマクロなどの機能についてお話ししましたまた参照カウントオーバーヘッドなしでリソース管理を提供できるパフォーマンス過敏コードや noncopyable型に触れました SwiftでC++ APIをサポートしコードにSwiftの利点を簡単にもたらす C++の共存機能についてお話ししました
最後に並行処理を楽に安全にするためデバイスや言語を通して Swiftの柔軟並行処理モデルがさまざまな環境にどのように適応するかお話ししました言語パラメータパックやマクロに non-copyable型と Swift 5.9でのすべての言語機能は Swift Evolution プロセスを通しオープンにデザイン・開発されそれにはコミュニティーの意見が重要な役割を果たしました Swift 5.9は活発なデザイン討論やバグレポートプルリクエストや教育コンテンツなど Swiftコミュニティの限りない貢献の極みです Swift 5.9が最高のリリースとなりみなさんに感謝しています ♪ ♪

3:06 - Hard-to-read compound ternary expression

let bullet =
    isRoot && (count == 0 || !willExpand) ? ""
        : count == 0    ? "- "
        : maxDepth <= 0 ? "▹ " : "▿ "

3:19 - Familiar and readable chain of if statements

let bullet =
    if isRoot && (count == 0 || !willExpand) { "" }
    else if count == 0 { "- " }
    else if maxDepth <= 0 { "▹ " }
    else { "▿ " }

3:30 - Initializing a global variable or stored property
```
let attributedName = AttributedString(markdown: displayName)
```

3:46 - In 5.9, if statements can be an expression

let attributedName = 
				if let displayName, !displayName.isEmpty {
            AttributedString(markdown: displayName)
        } else {
            "Untitled"
        }

4:31 - In Swift 5.7, errors may appear in a different place

struct ContentView: View {
    enum Destination { case one, two }

    var body: some View {
        List {
            NavigationLink(value: .one) { // The issue actually occurs here
                Text("one")
            }
            NavigationLink(value: .two) {
                Text("two")
            }
        }.navigationDestination(for: Destination.self) {
            $0.view // Error occurs here in 5.7
        }
    }
}

4:47 - In Swift 5.9, you now receive a more accurate compiler diagnostic

struct ContentView: View {
    enum Destination { case one, two }

    var body: some View {
        List {
            NavigationLink(value: .one) { //In 5.9, Errors provide a more accurate diagnostic
                Text("one")
            }
            NavigationLink(value: .two) {
                Text("two")
            }
        }.navigationDestination(for: Destination.self) {
            $0.view // Error occurs here in 5.7
        }
    }
}

5:47 - An API that takes a request type and evaluates it to produce a strongly typed value

struct Request<Result> { ... }

struct RequestEvaluator {
    func evaluate<Result>(_ request: Request<Result>) -> Result
}

func evaluate(_ request: Request<Bool>) -> Bool {
    return RequestEvaluator().evaluate(request)
}

6:03 - APIs that abstract over concrete types and varying number of arguments

let value = RequestEvaluator().evaluate(request)

let (x, y) = RequestEvaluator().evaluate(r1, r2)

let (x, y, z) = RequestEvaluator().evaluate(r1, r2, r3)

6:35 - Writing multiple overloads for the evaluate function

func evaluate<Result>(_:) -> (Result)

func evaluate<R1, R2>(_:_:) -> (R1, R2)

func evaluate<R1, R2, R3>(_:_:_:) -> (R1, R2, R3)

func evaluate<R1, R2, R3, R4>(_:_:_:_:)-> (R1, R2, R3, R4)

func evaluate<R1, R2, R3, R4, R5>(_:_:_:_:_:) -> (R1, R2, R3, R4, R5)

func evaluate<R1, R2, R3, R4, R5, R6>(_:_:_:_:_:_:) -> (R1, R2, R3, R4, R5, R6)

6:47 - Overloads create an arbitrary upper bound for the number of arguments

//This will cause a compiler error "Extra argument in call"
let results = evaluator.evaluate(r1, r2, r3, r4, r5, r6, r7)

7:12 - Individual type parameter
```
<each Result>
```
7:36 - Collapsing the same set of overloads into one single evaluate function
```
func evaluate<each Result>(_: repeat Request<each Result>) -> (repeat each Result)
```

8:21 - Calling updated evaluate function looks identical to calling an overload

struct Request<Result> { ... }

struct RequestEvaluator {
    func evaluate<each Result>(_: repeat Request<each Result>) -> (repeat each Result)
}

let results = RequestEvaluator.evaluate(r1, r2, r3)

10:01 - It isn't clear why an assert function fails
```
assert(max(a, b) == c)
```

10:20 - XCTest provides an assert-equal operation

XCAssertEqual(max(a, b), c) //XCTAssertEqual failed: ("10") is not equal to ("17")

11:02 - Assert as a macro
```
#assert(max(a, b) == c)
```
11:42 - Macros are distributed as packages
```
import PowerAssert
#assert(max(a, b) == c)
```
12:07 - Macro declaration for assert
```
public macro assert(_ condition: Bool)
```

12:26 - Uses are type checked against the parameters

import PowerAssert
#assert(max(a, b)) //Type 'Int' cannot be a used as a boolean; test for '!= 0' instead

12:52 - A macro definition

public macro assert(_ condition: Bool) = #externalMacro(
    module: “PowerAssertPlugin”,
    type: “PowerAssertMacro"
)

13:11 - Swift compiler passes the source code for the use of the macro
```
#assert(a == b)
```

13:14 - Compiler plugin produces new source code, which is integrated back into the Swift program

PowerAssert.Assertion(
    "#assert(a == b)"
) {
    $0.capture(a, column: 8) == $0.capture(b, column: 13)
}

13:33 - Macro declarations include roles

// Freestanding macro roles

@freestanding(expression)
public macro assert(_ condition: Bool) = #externalMacro(
    module: “PowerAssertPlugin”,
    type: “PowerAssertMacro"
)

13:53 - New Foundation Predicate APIs uses a `@freestanding(expression)` macro role

let pred = #Predicate<Person> {
    $0.favoriteColor == .blue
}

let blueLovers = people.filter(pred)

14:14 - Predicate expression macro

// Predicate expression macro

@freestanding(expression) 
public macro Predicate<each Input>(
    _ body: (repeat each Input) -> Bool
) -> Predicate<repeat each Input>

14:48 - Example of a commonly used enum

enum Path {
    case relative(String)
    case absolute(String)
}

15:01 - Checking a specific case, like when filtering all absolute paths
```
let absPaths = paths.filter { $0.isAbsolute }
```

15:09 - Write an `isAbsolute` check as a computer property...

extension Path {
    var isAbsolute: Bool {
        if case .absolute = self { true }
        else { false }
    }
}

15:12 - ...And another for `isRelative`

extension Path {
    var isRelative: Bool {
        if case .relative = self { true }
        else { false }
    }
}

15:17 - Augmenting the enum with an attached macro

@CaseDetection
enum Path {
    case relative(String)
    case absolute(String)
}

let absPaths = paths.filter { $0.isAbsolute }

15:36 - Macro-expanded code is normal Swift code

enum Path {
    case relative(String)
    case absolute(String)
  
    //Expanded @CaseDetection macro integrated into the program.
    var isAbsolute: Bool {
        if case .absolute = self { true }
        else { false }
    }

    var isRelative: Bool {
        if case .relative = self { true }
        else { false }
    }
}

16:57 - Observation in SwiftUI prior to 5.9

// Observation in SwiftUI

final class Person: ObservableObject {
    @Published var name: String
    @Published var age: Int
    @Published var isFavorite: Bool
}

struct ContentView: View {
    @ObservedObject var person: Person
    
    var body: some View {
        Text("Hello, \(person.name)")
    }
}

17:25 - Observation now

// Observation in SwiftUI

@Observable final class Person {
    var name: String
    var age: Int
    var isFavorite: Bool
}

struct ContentView: View {
    var person: Person
    
    var body: some View {
        Text("Hello, \(person.name)")
    }
}

17:42 - Observable macro works with 3 macro roles

@attached(member, names: ...)
@attached(memberAttribute)
@attached(conformance)
public macro Observable() = #externalMacro(...).

17:52 - Unexpanded macro

@Observable final class Person {
    var name: String
    var age: Int
    var isFavorite: Bool
}

18:05 - Expanded member attribute role

@Observable final class Person {
    var name: String
    var age: Int
    var isFavorite: Bool
  
		internal let _$observationRegistrar = ObservationRegistrar<Person>()
    internal func access<Member>(
        keyPath: KeyPath<Person, Member>
    ) {
        _$observationRegistrar.access(self, keyPath: keyPath)
    }
    internal func withMutation<Member, T>(
        keyPath: KeyPath<Person, Member>,
        _ mutation: () throws -> T
    ) rethrows -> T {
        try _$observationRegistrar.withMutation(of: self, keyPath: keyPath, mutation)
    }
}

18:12 - Member attribute role adds `@ObservationTracked` to stored properties

@Observable final class Person {
    @ObservationTracked var name: String
    @ObservationTracked var age: Int
    @ObservationTracked var isFavorite: Bool
  
		internal let _$observationRegistrar = ObservationRegistrar<Person>()
    internal func access<Member>(
        keyPath: KeyPath<Person, Member>
    ) {
        _$observationRegistrar.access(self, keyPath: keyPath)
    }
    internal func withMutation<Member, T>(
        keyPath: KeyPath<Person, Member>,
        _ mutation: () throws -> T
    ) rethrows -> T {
        try _$observationRegistrar.withMutation(of: self, keyPath: keyPath, mutation)
    }
}

18:16 - The @ObservationTracked macro adds getters and setters to stored properties

@Observable final class Person {
    @ObservationTracked var name: String { get { … } set { … } }
    @ObservationTracked var age: Int { get { … } set { … } }
    @ObservationTracked var isFavorite: Bool { get { … } set { … } }
  
		internal let _$observationRegistrar = ObservationRegistrar<Person>()
    internal func access<Member>(
        keyPath: KeyPath<Person, Member>
    ) {
        _$observationRegistrar.access(self, keyPath: keyPath)
    }
    internal func withMutation<Member, T>(
        keyPath: KeyPath<Person, Member>,
        _ mutation: () throws -> T
    ) rethrows -> T {
        try _$observationRegistrar.withMutation(of: self, keyPath: keyPath, mutation)
    }
}

18:33 - All that Swift code is folded away in the @Observable macro

@Observable final class Person {
    var name: String
    var age: Int
    var isFavorite: Bool
}

23:59 - A wrapper for a file descriptor

struct FileDescriptor {
    private var fd: CInt
  
    init(descriptor: CInt) { self.fd = descriptor }

    func write(buffer: [UInt8]) throws {
        let written = buffer.withUnsafeBufferPointer {
            Darwin.write(fd, $0.baseAddress, $0.count)
        }
        // ...
    }
  
    func close() {
        Darwin.close(fd)
    }
}

24:30 - The same FileDescriptor wrapper as a class

class FileDescriptor {
    private var fd: CInt
  
    init(descriptor: CInt) { self.fd = descriptor }

    func write(buffer: [UInt8]) throws {
        let written = buffer.withUnsafeBufferPointer {
            Darwin.write(fd, $0.baseAddress, $0.count)
        }
        // ...
    }
  
    func close() {
        Darwin.close(fd)
    }
    deinit {
        self.close(fd)
    }
}

25:05 - Going back to the struct

struct FileDescriptor {
    private var fd: CInt
  
    init(descriptor: CInt) { self.fd = descriptor }

    func write(buffer: [UInt8]) throws {
        let written = buffer.withUnsafeBufferPointer {
            Darwin.write(fd, $0.baseAddress, $0.count)
        }
        // ...
    }
  
    func close() {
        Darwin.close(fd)
    }
}

26:06 - Using Copyable in the FileDescriptor struct

struct FileDescriptor: ~Copyable {
    private var fd: CInt
  
    init(descriptor: CInt) { self.fd = descriptor }

    func write(buffer: [UInt8]) throws {
        let written = buffer.withUnsafeBufferPointer {
            Darwin.write(fd, $0.baseAddress, $0.count)
        }
        // ...
    }
  
    func close() {
        Darwin.close(fd)
    }
  
    deinit {
        Darwin.close(fd)
    }
}

26:35 - `close()` can also be marked as consuming

struct FileDescriptor {
    private var fd: CInt
  
    init(descriptor: CInt) { self.fd = descriptor }

    func write(buffer: [UInt8]) throws {
        let written = buffer.withUnsafeBufferPointer {
            Darwin.write(fd, $0.baseAddress, $0.count)
        }
        // ...
    }
  
    consuming func close() {
        Darwin.close(fd)
    }
  
    deinit {
        Darwin.close(fd)
    }
}

26:53 - When `close()` is called, it must be the final use

let file = FileDescriptor(fd: descriptor)
file.write(buffer: data)
file.close()

27:20 - Compiler errors instead of runtime failures

let file = FileDescriptor(fd: descriptor)
file.close() // Compiler will indicate where the consuming use is
file.write(buffer: data) // Compiler error: 'file' used after consuming

28:52 - Using C++ from Swift

// Person.h
struct Person {
    Person(const Person &);
    Person(Person &&);
    Person &operator=(const Person &);
    Person &operator=(Person &&);
    ~Person();
  
    std::string name;
    unsigned getAge() const;
};
std::vector<Person> everyone();

// Client.swift
func greetAdults() {
    for person in everyone().filter { $0.getAge() >= 18 } {
        print("Hello, \(person.name)!")
    }
}

29:51 - Using Swift from C++

// Geometry.swift
struct LabeledPoint {
    var x = 0.0, y = 0.0
    var label: String = “origin”
    mutating func moveBy(x deltaX: Double, y deltaY: Double) { … }
    var magnitude: Double { … }
}

// C++ client
#include <Geometry-Swift.h>

void test() {
    Point origin = Point()
    Point unit = Point::init(1.0, 1.0, “unit”)
    unit.moveBy(2, -2)
    std::cout << unit.label << “ moved to “ << unit.magnitude() << std::endl;
}

35:30 - An actor that manages a database connection

// Custom actor executors

actor MyConnection {
    private var database: UnsafeMutablePointer<sqlite3>
  
    init(filename: String) throws { … }
  
    func pruneOldEntries() { … }
    func fetchEntry<Entry>(named: String, type: Entry.Type) -> Entry? { … }
}

await connection.pruneOldEntries()

35:58 - MyConnection with a serial dispatch queue and a custom executor

actor MyConnection {
  private var database: UnsafeMutablePointer<sqlite3>
  private let queue: DispatchSerialQueue
  
  nonisolated var unownedExecutor: UnownedSerialExecutor { queue.asUnownedSerialExecutor() }

  init(filename: String, queue: DispatchSerialQueue) throws { … }
  
  func pruneOldEntries() { … }
  func fetchEntry<Entry>(named: String, type: Entry.Type) -> Entry? { … }
}

await connection.pruneOldEntries()

36:44 - Dispatch queues conform to SerialExecutor protocol

// Executor protocols

protocol Executor: AnyObject, Sendable {
    func enqueue(_ job: consuming ExecutorJob)
}

protocol SerialExecutor: Executor {
    func asUnownedSerialExecutor() -> UnownedSerialExecutor
    func isSameExclusiveExecutionContext(other executor: Self) -> Bool
}

extension DispatchSerialQueue: SerialExecutor { … }

39:22 - C++ implementation of FoundationDB's "master data" actor

// C++ implementation of FoundationDB’s “master data” actor

ACTOR Future<Void> getVersion(Reference<MasterData> self, GetCommitVersionRequest req) {
  	state std::map<UID, CommitProxyVersionReplies>::iterator proxyItr = self->lastCommitProxyVersionReplies.find(req.requestingProxy);
  	++self->getCommitVersionRequests;

  	if (proxyItr == self->lastCommitProxyVersionReplies.end()) {
      	req.reply.send(Never());
    	  return Void();
  	}
  	wait(proxyItr->second.latestRequestNum.whenAtLeast(req.requestNum - 1));
  
  	auto itr = proxyItr->second.replies.find(req.requestNum);
  	if (itr != proxyItr->second.replies.end()) {
    		req.reply.send(itr->second);
    		return Void();
  	}

  	// ...
}

40:18 - Swift implementation of FoundationDB's "master data" actor

// Swift implementation of FoundationDB’s “master data” actor
func getVersion(
    myself: MasterData, req: GetCommitVersionRequest
) async -> GetCommitVersionReply? {
    myself.getCommitVersionRequests += 1

    guard let lastVersionReplies = lastCommitProxyVersionReplies[req.requestingProxy] else {
        return nil
    }

    // ...
    var latestRequestNum = try await lastVersionReplies.latestRequestNum
          .atLeast(VersionMetricHandle.ValueType(req.requestNum - UInt64(1)))

    if let lastReply = lastVersionReplies.replies[req.requestNum] {
        return lastReply
    }
}

特定のトピックをお探しの場合は、上にトピックを入力すると、関連するトピックにすばやく移動できます。

クエリの送信中にエラーが発生しました。インターネット接続を確認して、もう一度お試しください。

関連する章

リソース

関連ビデオ

WWDC23

WWDC21