Swiftの最新情報

Swiftの最新情報

Swiftの最新情報を紹介します。パフォーマンスの向上について解説します。より安全で拡張可能なSwiftパッケージを詳しく紹介しますので、Swiftの同時実行性がどれほど進歩したかご覧ください。また、Swift Regex、優れたジェネリクス、言語に組み込まれた他のツールも紹介します。これで、より柔軟で表現力の高いコードを作成できるようになります。

リソース
関連ビデオ

WWDC22
ダウンロード

♪ 落ち着いた雰囲気のヒップホップ音楽 ♪ ♪ こんにちは私はAngelaです私はBeccaです『Swiftの最新情報』へようこそ本日はSwift 5.7.のすばらしい新機能をすべて紹介できることにワクワクしています本日お話しする多くの内容はデベロッパの仕事を楽にするという Swiftの目標を立証します皆さんがワークフローをカスタマイズするための新しいツールをご紹介しすばらしい内部改善をいくつかご紹介します次にSwiftの並行処理モデルの最新情報と完全なスレッド安全を含む Swift 6への道をご紹介しますそして最後により明確でシンプルになったジェネリクスを含むSwiftでの読み書きを容易にする言語の改善についてと新しい協力な文字列処理機能についてお話します話を始めるまえにSwiftが実に特別である理由の１つについてお話ししましょうそれは皆さんです Swiftが急速に成長できたのは皆さんのご意見や貢献のおかげですコミュニティは Swiftにとって欠かせない存在ですドキュメント生成ツールDocC が去年発表され Swift.orgウェブサイトがオープンソースになって以来今年 Swift ではより多くのプロジェクトがコミュニティで利用可能になりましたオープンソースは活動的なコミュニティにより導かれることで最大の力を発揮します Swift on Serverではワークグループモデルと Diversity in Swiftを使用し特定の分野に興味を持つコミュニティメンバーに管理とサポートを提供してきましたこれが良好に進んでおり新しいグループを２つ開始しました１つはSwiftウェブサイトで反復するものでコミュニティのリソース的な存在となりもう１つはC++ 相互運用性向けで C++とSwift間のモデルの設計を形成します新しい領域に入ることによりコミュニティのメンバーからのサポートが必要になりますその一部としてDiversity in Swiftワークグループは去年 Swiftメンタープログラムを開始しましたこのプログラムは何から始めていいかわらない人や特定の領域で専門知識を深めたい人のためにすべてのワークグループに役立つ進路を提供します去年のプログラムは大成功を収めました興味を持ったメンティがたくさんいましたその結果 41のペアを作ることができました去年の成功により今年もこのプログラムが実施されることになったのです興味を持つ方全員に参加していただくには皆さんのような今これをご覧の積極的で経験豊富な幅広い知識を提供し新しいつながりを作りたいデベロッパの協力が必要ですメンタープログラムで重要なのはコードだけでなくコミュニティ内で関係を築くことも重要ですまた少しのガイダンスが永続的な効果につながりますそれを確信するのは私だけではありません去年アムリットはこのプログラムに参加しコンパイラと言語設計に注力しました最初は好奇心から参加したプログラムが目に見える貢献に変わりました新しい領域に入るのは簡単ではありませんがそれでも結果的に成功をおさめさらに貢献するよう刺激を受けました他の多くの人と同様にこの体験でアムリは多くの機会を得ましたコンパイラと言語設計に加え去年技術文書の作成やテストに始まり投稿からSwift パッケージまで広範囲の焦点領域が利用可能でした今年は領域がさらに増えました新しいトピックに関する機会も常にあります興味のある領域がこの画面にない場合申請書にそれを記入することができますさらに今年のプログラムでは参加したいけれども能力がまだ低い人のためにスターターバグ投稿用に１年間のメンタリングを提供します申請に興味がある場合や詳細を知りたい場合は最新の Swift ブログ投稿をご覧ください注目のメンティーからの詳細な考察を確認できますメンタープログラムはDiversity in Swiftが提供するイニシアチブのほんの一部ですメンタープログラムの詳細やその他のDiversity in Swift 取り組みについては Swift.org/diversityをご覧ください扉をより開放的にするために皆さんがお持ちのリソースで Swiftを使いやすくしました Linuxパッケージ形式へのサポートを追加し Swiftツールチェーン配信プロセスを Linuxプラットフォーム向けに合理化しました新しいネイティブツールチェインインストーラでは Amazon Linux 2のRPMとCentOS 7が Swift.orgから直接ダウンロードできますこのツールチェーンは実験的なものですので Swift.orgフォーラムで感想をお聞かせください Swiftは基本的にAppの構築に使用されますしかしSwiftは高レベルのスクリプトの使用からベアメタル環境まであらゆるものを使用してスケーラブルにすることが構想されてきましたこれまでに使用されていない方法で Swiftが使用されるのを奨励するために今年は Swiftにいくつかの大きな変更が行われましたスタンドアローン静的リンクバイナリ用に標準ライブラリを縮小し外部のUnicodeサポートライブラリへの依存を中止しより迅速なネイティブ実装に置き換えましたより小型で迅速なバイナリはイベント駆動型サーバソリューションで実行された場合に利点となります Linuxではデフォルトで静的リンクが装備されておりサーバのコンテナ化された展開のサポートが向上しますこのサイズ縮小によりSwiftはより制限された環境にも適合するようになり AppleのSecure Enclaveでも使用できるようになります SwiftはAppやサーバーから制限付きプロセッサで役に立ちますこれをすべて結びつけるのがパッケージエコシステムです Swift パッケージの今年の新機能は皆さんの生活を楽にしますまずSwift Package Manager TOFUが発表されました食べ物ではありません TOFUはTrust On First Useの頭字語です新しいセキュリティプロトコルでパッケージが最初にダウンロードされた時にパッケージの指紋が記録されますその後のダウンロードではこの指紋が検証され指紋が違う場合はエラーが発生しますこれは信頼とセキュリティがパッケージのエコシステムの中心に構築されており自信を持って使用できることを証明できる例の１つですコマンドプラグインはSwiftデベロッパがワークフローを改善するのに最適ですこれは拡張可能で安全なビルドツールを提供するための最初のステップですこの機能はドキュメント生成やソースコード再編成などに使用できますシェルスクリプトで自動化を書き異なるワークフローを維持する代わりにSwiftを使えますオープンソースフォーマッタやリンタを考えてくださいすべてのオープンソースツールは Xcodeと Swift Package Managerでご利用いただけますコマンドプラグインはオープンソースツールと Swift Package Managerの接着剤となります Swiftプロジェクトは自動ワークフローでシームレスな統合を提供するためにオープンソースコミュニティのデベロッパツールを奨励します docC はソースコードでドキュメントを統合するのにすばらしいツールです今年は Objective-C と C サポートでさらに向上しました DocCでプラグインを作成する方法を見てみましょうプラグインはシンプルなSwift コードですプラグインを定義するにはCommandPluginにプロトコルに同調するStrutを作成します次にどのツールを呼び出すかを伝える関数を追加するだけですこの関数内でdocCを呼び出しますプラグインを定義したら Swift PM コマンドラインインターフェースを介してメニューエントリとして Xcodeで利用可能になりますこれでSwift PMがドキュメントを作成しアクションをdocC実行ファイルにパスすることがわかりますまだ続きますビルドツールプラグインという別のプラグインがありこのプラグインはパッケージでビルド中に追加のステップを導入しますビルドツールプラグインを導入するとビルドシステムのコマンドが生成されサンドボックスで実行されますいつでも直接実行ファイルでパッケージのファイルを変更するために明確な許可を受けることができるコマンドプラグインとは異なりますビルドツールプラグインはソースコード生成か特別な型のファイルのカスタム処理で使用できますこれがビルドツールプラグインのパッケージレイアウトですこの例ではplugin.Swiftはパッケージプラグインターゲットを実装する SwiftスクリプトですプラグインはSwift実行ファイルとして対処され他のSwift実行ファイルと同じようにプラグインを書きますどの実行ファイルコマンドを実行しその結果どの出力が期待されるかをビルドシステムに伝える一連のビルドコマンドを定義してプラグインを実装できますパッケージプラグインはセキュアなソリューションでパッケージに拡張可能性を提供しますプラグインの仕組みと自身のプラグインの実装方法については２つのセッションをご覧ください『Swift Packageプラグインの紹介』『Swift Packageプラグインを作成する』パッケージの使用方法が増大するとともにモジュールの衝突が起こるかもしれませんそれは２つの異なるパッケージがモジュールを同じ名前で定義すると起こりますこれを解決するために Swift 5.7はモジュール曖昧性解除を導入しましたこれはモジュールが定義されたパッケージの外でモジュールの名前を変更できる機能ですここにすばらしいAppがありますログインモジュールを定義した２つのパッケージを呼び出すと衝突しました Stunning App用にこれを修正するには moduleAliasesキーワードをパッケージマニフェストのdependencies セクションに追加しますそうすることで名前が同じだった２つのモジュールに別々の名前を付けることができます Swift 5.7ではパフォーマンスも向上しましたビルド時間を見てみましょう去年 Swift Driverを書き直したことについてお話ししました SwiftのSwiftソースコードコンパイルを調整するプログラムです去年の再構築によりビルドを著しくスピードアップするための重要な変更が行われました今回ドライバは別の実行ファイルではなく Xcodeビルドシステムの中からフレームワークとして直接使用できるようになりましたこれでビルドシステムを使ってビルドをより詳細に調整でき並列化などが可能になりますすばやいビルドに興味がある方は『Xcodeビルドでの並列化に関する解説』セッションで詳細をご覧くださいビルドの速度を証明するために Swiftで書かれた頻繁に使用するツールの構築時間の例をお見せしましょう 10-core iMacでの速度改善は５～25％です次は型検査の速度の改善についてです今年ジェネリクスシステムの主要な部分を再実装し型検査のパフォーマンスを改善しましたプロトコルや「where」句などから関数シグネチャを計算する部分です以前の実装では時間のメモリの使用量は関連するプロトコルが増えると急激に拡大しましたたとえばここには調整システムを定義する複雑な一連のプロトコルと多くの関連型でたくさんのジェネリック要件があります以前このコードの型検査には 17秒かかりましたが Swift 5.7ではこの例に対して１秒以下と著しく迅速になっています実行時間においても同等に改善しています Swift 5.7以前でのApp起動のプロトコル検査は iOSで最大４秒かかりました Appを起動するたびにプロトコルが必要でプロトコルが追加されるたびに起動時間がより長くなりました現在ではキャッシュされます Appの書き方によりまた使用されるプロトコルの数により iOS 16でAppが起動される場合起動時間が半分になります『Appサイズとランタイムパフォーマンスの改善』では自身のAppでこれらの改善を活用する方法が説明されていますでは皆さんが待ちに待っていた情報をお伝えしましょう去年私たちはactorsやasync/awaitと共に新しい並列化モデルを発表しましたこれは皆さんのAppの並列アーキテクチャに改革的な効果をもたらしました Async/awaitとactorsはcallbackや手動の待ち行列管理よりも安全かつ簡単です今年は最前部でのデータ競合安全性でモデルをさらに強化しました並列化はAppのコードベースにとって非常に基礎的で重要であるためこの変更をiOS 13とmacOS Catalinaで再デプロイできるようにしました旧式のOSにデプロイするには Appは旧式のOS用にSwift 5.5 並列ランタイムのコピーを一括しますこれはABI Stability以前のオペレーティングシステムに Swiftを再デプロイするのと似ています次にこの新しいモデルを新しい方向に導きました言語機能とサポートパッケージを導入しましたまずデータ競合の回避について説明しますその前に少し戻ってお伝えすべきことは Swiftで最も重要な機能の１つがデフォルトのメモリ安全性だということです Swiftユーザは値を変更しながら読むなど予測不可能な動作で何かをすることはできませんこの例では同じ配列のcountに一致する配列にある数字を削除しました最初の配列のcountは３なので配列から３を削除しますしかしそうするとcountは２になりますでは配列から３と２の両方を削除するのか３だけを削除するのか？答えはどちらでもありません Swiftはこれが行われるのを防止します変更中に配列のcountにアクセスするのは危険だからです同類のことをしてスレッドの安全を守るのが目標です私たちはデフォルトで起こる低レベルのデータ競合を消去する言語を想定しました言い換えると予期せぬ動作を起こす並列バグを防止するという意味です別の例をお見せしましょう同じ数字の配列を使い０を配列に追加するバックグラウンドタスクを作成し配列の最後の要素を削除しますおっと　でも最後の要素の削除は０の追加の前に起こるのか後に起こるのか？ここでも答えはどちらでもありません actorなどでアクセスを同期せずにバックグラウンドタスクから配列を変更するのは危険であるため Swiftはこれが行われるのを防止します Actorはデータ競合排除への最初のビッグステップです今年は最終目標に前進するために並列化モデルを微調整しましたそれぞれの actor を並列化の海で孤立している島だと考えてくださいしかし異なるスレッドが各actorに保存されている情報をクエリするとどうなるでしょうか？このメタファーはこちらのセッションで説明されています『Swiftの並行処理でデータ競合を排除する』メモリ安全からデフォルトのスレッド安全それがSwift 6の目標ですそれを実現するためにまず去年の並列化モデルを先程申し上げた新しい言語機能で更新しましたもう１つまだお伝えしていない事は潜在的なデータ競合を特定するオプトイン安全チェックですより厳密な並列検査を行いたい場合はビルド設定で有効にできますではもう一度actorを見てみましょうこのactorの概念を分散actorで掘り下げてみましょう分散actorはネットワークを境に島を別のマシンに配置しますこの新しい言語機能は分散システムの開発をよりシンプルにしましたゲームAppを作成したいとしましょう Swiftならバックエンドを簡単に書けますここでは分散actorはactorのようですが異なるマシンにいる場合がありますこの例ではユーザとのゲーム中に状態を維持するコンピュータプレイヤに目を向けています分散キーワードはリモートマシンにいる actorを呼び出す必要があると期待する関数に追加することもできます endOfRoundという関数も追加しましょうプレイヤごとに繰り返され makeMoveを呼び出しますローカルとリモートのプレイヤがいますが誰が誰かを気にする必要はありません通常のactor呼び出しと違うのは分散actorの呼び出しはネットワークエラーにより失敗する可能性があるところですネットワークの障害が起こった場合 actorメソッドはエラーを出すので try キーワードの追加と actor外で関数を呼び出した時のために await キーワードの追加が必要になりますコア言語のプリミティブを構築することで Swiftでサーバーサイドのクラスタ化された分散システムの構築に集中したオープンソースの Distributed Actorsパッケージも構築しましたこのパッケージにはSwiftNIOを使用した統合されたネットワーク層が含まれクラスタの状態を管理するSWIM consensus protocolを実装しました『Swiftの分散アクタの紹介』ではこれらの新しい機能で分散システムを構築する方法が説明されていますまた AsyncSequenceに対処する場合の一般的な操作ですぐに使えるソリューションを提供するために Swift 5.5.でリリースされた新しいオープンソースの一連のアルゴリズムを発表しましたこれらのAPIをパッケージとして提供することでデベロッパはプラットフォームや OSバージョンのデプロイで柔軟性が持てます複数の非同期シーケンスを組み合わせ値をコレクションにグループ化する方法がいくつかありますこれはパッケージに含まれているいくつかのアルゴリズムです『Swift Async Algorithmsについて』でこの強力なAPIの使用方法を確認できますしかし並列化にはパフォーマンスという別の側面があります今年はactorの優先度付けで actorsは優先度が最も高い作業から実行できオペレーティングシステムスケジューラでディープインテグレーションを続行できるようになりましたモデルには優先順位の逆転防止が内蔵されているので重要度の低い作業が高い作業を阻止することはできません以前はAppで並列のパフォーマンスの影響を視覚化するのは困難でしたがそれを行うためのすばらしいツールが開発されました Instruments の Swift Concurrencyビューはパフォーマンスの問題の調査に役立ちます Swift TaskとActors instrumentsは並列コードを視覚化最適化するためのツール一式を提供します Swift Tasks Instrument上部には同時に実行されているタスクの数やその時点までに作成されたタスクの合計数など有益な統計を提供しますこのウィンドウの下半分では Task Forestと呼ばれるものがありますこれは構造化並列コードのタスク間の親子関係を図形表現したものですこれはSwift Actor Instrumenttの詳細なビューの１つですこの期待の新しいツールを使用する方法は『Swiftの並行処理を視覚化して最適化する』をご覧くださいまた新しいパッケージの使用もお忘れなくそしてフォーラムで感想をお聞かせくださいでは次はBeccaがSwift言語のユーザビリティの改善についてお話しします言語はツールですそしてこのツールの面白い点は構築するものに影響を与えるところですハンマーしかない場合に何かを構築する場合はネジでなくクギを使いますツールが一式揃っていたとしてもハンマーの柄が握りやすくスクリュードライバーは握りにくい場合クギを使うことを選択するかもしれません言語も同じです何かを表現するための適したツールが Swiftにあればより頻繁に使用するでしょう今年コードに実行してもらいたい作業を表現するためのツールが多くの方法で改善されましたこれらの変更の一部は頻繁に行うことに対する便利性のためのものです例えば Swift では等号の両側の名前が同じなら if letを使用するのは一般的です結局のところラップされていない値にはオプションのものに付けた名前より良い名前はないでしょうしかし名前が長い場合その反復が面倒になってきます名前を省略したくなりますがそうするとコードが不可解になります後にオプション変数の名前を変更しても省略が同期しなくなります Swift 5.7ではこの一般的なパターン向けに新しい省略表現を導入しましたオプションのラップをほどきラップされていない値に同じ名前を付ける場合は右側を削除すればいいだけです Swiftは同じだと推測します guardでも同じ効果があります even whileでも同じです小さな変更を加えた時に機能が動作しなくなる点にも目を向けました例えば Swiftは単一のステートメントクロージャ内に書かれたコードに基づいてどの呼び出しを返すか常に考えだしますこのcompactMap呼び出しではクロージャはparseLineの値を返しparseLine関数は MailmapEntryを返すのでSwiftはエントリが MailmapEntryの配列であるべきだと解明しますこれで複数のステートメント制御フロー機能などより複雑なクロージャでも機能するようになり do-catchやif...elseを使用したりクロージャの結果型を手動で指定することなく print呼び出しを追加したりできますまた実際の危険を警告しない危険フラグにも目を向けました Swiftは型とメモリの安全を懸念しています皆さんがミスをしないようにポインタを異なるポインタ型に自動的に変換することや生ポインタを型ポインタに変換することはしませんこれは特定の変換を許可する Cとは非常に異なります例えばポインタが指す値の符号属性の変更や Cのポインタ規則を破ることなくポインタを char *に型変換しバイトとしてアクセスしますしかしC APIがSwiftにインポートされた場合ポインタの動作が問題を起こす場合があります元のデベロッパがわずかに不一致した APIを設計しCでは自動変換が処理され Swiftではエラーになります Swiftで１つのポインタを異なる型のようにアクセスするのは非常に危険ですそのため動作を明確に説明する必要がありますしかしポインタを直接Cにパスするならそれは無意味ですなぜならCではポインタの不一致は完全に合法だからですですのでこのケースでは率直に危険であることにして対処しましたこれが重要なのは Swiftは安全性を重要視しますが C系のコードも大切にするからですだから CとObjective-C 相互運用性は非常に充実しシームレスなのですまた Angelaの先述のように同等な機能を持つ C++ 相互運用性を構築するための C++ワーキンググループができたのもそのためですこのようなC関数を使って不必要な面倒を起こしたくありませんそこで Swiftにはインポートされた機能やメソッドに対する別の規則セットが作成されました通常SwiftではできないCでは合法なポインタ変換を可能にしますこれでSwiftコードをAPIでシームレスに使用できますここまでは皆さんがすでにお持ちのツールの小さな改善についてお話ししましたしかし今年は Swift文字列から情報を抽出するための真新しいツールが作成されましたこれは文字列から情報を解析する関数ですこの類のタスクは Swiftでは常に挑戦的でした望むものを得るまで検索分割スライスを何度も繰り返す必要がありました人はこれに気づいた場合文字列のインデックスを操作するにはいかに言葉が冗長するかと小さなことに気を配りますしかしそうなると全体像を見逃しがちですなぜならこの構文を変えたとしてもこのコードを見た時に質問している基本的な答えが出ませんここにパスされる行変数は実際にどんなものであるか？どんな文字列を分解しようとしているのか？長く見つめていると簡素化されたmailmapを解析し gitリポジトリに保管したファイルでデベロッパの名前を修正しようとしてますしかしその情報の抽出に検索とスライスが深く関与しており理解することができません文字列のスライスで混乱しどの文字列だったかを思い出すのに苦労します問題はこの２つの表現ではなく全体にありますこれを全部取り除きより優れたものに置き換える必要があります別のアプローチが必要です１つはコードが一致させたい文字列の絵を描き言語がその方法を考え出します命令的ではなく宣言的なアプローチです Swift 5.7では正規表現を書くことでそれが実現します正規表現は文字列のパターンを説明する方法です 50年以上言語とツールはデベロッパが高密度で情報が詰まった構文を書くことを許可してきました一部の皆さんはすでにFoundationの NSRegularExpressionクラスの grepなどのコマンドラインのXcode検索バーや他のプログラミング言語でご使用でしょうその構文がSwiftの正規表現リテラルで利用可能になり他のデベロッパツールと同様に機能しますしかしまだ正規表現を使用したことがなく「それって本物のコード？」と思う方もいらっしゃるでしょう無理もありませんこれはシンボルやニーモニックで書かれており読むためにはこれらを記憶する必要がありますこの言語を知っている方にとってデベロッパの名前に一致するなどこの正規表現がすごいと感じる部分はいくつかの単純な一致条件が組み合わされただけですしかし11文字に詰め込むにはかなりの数の動作です非常に圧縮されており経験豊富なデベロッパでさえ複雑なものを理解するのに時間を要することがありますしかしシンボルの代わりに言葉で同じ種類の一致条件を書けるなら？理解しやすくなりそうですね実際にこれを１つにまとめると SwiftUIにかなり似ています正規表現リテラルのすばらしい代用となりますなのでSwiftがこれをサポートするのはすばらしいことです RegexBuilderライブラリは正規表現のための新しいSwiftUI式の言語を提供し従来の構文よりも使いやすく読みやすくなっています正規表現リテラルと同じ機能を果たしますが記憶が必要なシンボルや省略表現の代わりに理解や検索可能な言葉で動作を説明します Regex ビルダは初心者に最適ですがこの機能は初心者専用ではありません正規表現リテラルの通常の機能以上の能力がありますまず正規表現を再利用可能な正規表現コンポーネントに変えることができます SwiftUIビュー階層をビューに変えるのと同じです Builder構文で作成された別の正規表現からのコンポーネントを使い再帰的にすることもできます正規表現ビルダは一部のSwift型を正規表現に直接入れることもサポートします例えば文字列リテラルは中のテキストと完全に一致し特別なエスケープ処理は必要ありません正規表現リテラルを正規表現ビルダの途中で使用することもでき正規表現ビルダの明確さとリテラルの簡潔さの間でバランスを保てます他にもこのFoundation 日付形式スタイルのように正規表現ビルダでカスタム解析ロジックを統合できデータを取得前にリッチ型に変換できます最後にどの構文を使っても正規表現は役に立つ多くの一致メソッドをサポートし使いやすい型付きキャプチャをサポートします椅子に座りながら身もだえしている正規表現のオタクに Swift Regexはほとんどの高度な正規表現実装に匹敵する機能セットが付いた最新のオープンソースマッチングエンジンを使いますリテラル構文は Unicode正規表現標準に対応し卓越したレベルのUnicode正確性を備えています例えば「点」はデフォルトですべての文字に一致し Unicode.ScalarやUTF-8バイトではありません Swift Regexを使用する場合AppはmacOS 13 またはiOS 16とSwift Regexエンジン内蔵の OSで実行される必要があります Swift Regexが全体の言語です実際には２つの言語ですなので他にもお伝えすることはあります『Swift Regexの紹介』『Swift Regex: 上級編』では使い方の詳細が説明されています最後は私たちが保有するツールを全体的に見て改善するために多くの変更を行った部分がありますそれはジェネリクスとプロトコルですこれがどのように改善されたかを説明するにはプロトコルの例が必要です gitクライアントを書いており mailmapを２つの異なる方法で表現する必要があります commitを表示するとディクショナリで型を使用し名前をすばやく検索しますしかしユーザがmailmapを編集する場合配列で型を使用し入力を元の順序で保ちます Mailmapというプロトコルがありどちらもそれに従うため mailmapパーサはエントリ追加ができますがパーサがMailmapプロトコルに使用できる方法は２つありますこのaddEntrieの２つの異なる関数で説明するつもりでしたがこの２つがどう異なるかを説明するのは困難ですなぜならSwiftは同じ構文を使っているからですここでは「Mailmap」の意味がこことはわずかに異なっていたのです
継承リストジェネリックパラメータリストジェネリックコンフォーマンスリスト不透明結果型でプロトコルに名前を付けると「このプロトコルに従うインスタンス」となり変数型ジェネリック引数ジェネリック同型制約関数パラメータまたは結果型では「このプロトコルに従うインスタンスを含むボックス」という意味になりますこの区別は重要ですなぜならこのボックスは通常場所を多く取り操作に時間がかかり中にはインスタンスのすべての機能がないからですしかしこのボックスを使用する場所は使っていない場所と見た目は一緒ですですので使用しているかどうかはわかりづらく Swift 5.7 はこの見過ごしを修正します適合型を含むボックスのいずれかを使用する場合 Swiftは皆さんがanyを入力することを期待しますこれはSwift 5.7以前では必須ではありませんでしたがこれを行うことが推奨されており明確に書かなかったとしてもインターフェースやエラーメッセージで表示されるようになります右側の列にある内容を書くために最適な方法はanyを使用することですそうすればボックスを使用しているとわかるようになりますこの例では anyがパラメータの１つに記入されているためこの２つの関数の違いがわかりやすくなりました addEntries1はMailmapをジェネリック型 addEntries2はany型として受け取りますまた any 型の制限に及んだ場合にエラーメッセージで状況を説明しやすくなります例えばこのmergeMailmaps関数は Mailmapをジェネリックパラメータにパスしようとし Mailmapは自身に適合できないというエラーメッセージが表示されます少し矛盾しているように見えますが今はany型の概念があるので何が起こっているかをより明確に説明できます問題はany Mailmap mailmapを含んでいるボックスが Mailmapプロトコルに適合しない点ですなのでそのボックスをパスしようとしてもジェネリックパラメータに適合しません中のインスタンスをパスしようとするとどうにかしてボックスを開き中のmailmapを出してパスしますがこのようなシンプルなケースの場合 Swiftが皆さんの代わりにそれを行ってくれますボックスを開き中のインスタンスを出しジェネリックパラメータにパスしてくれますなのでこのエラーメッセージはあまり表示されなくなります anyよりもさらに嬉しい改善があります以前プロトコルがセルフ型や関連型を使用した場合 any型として使用できませんでした Equatableのようにプロトコルに適合することもできませんでしたしかしSwift 5.7ではこのエラーが… フ～消えました多くのデベロッパがこれで苦労しているのでソースで修正できたことに満足しています Mailmapなどには十分な修正ですが改善はまだ続きます Collectionのような洗練されたプロトコルでさえ any型として使用できるようになりました要素型を指定することもできます新機能「primary associated types」のおかげです多くのassociated typeは基本的にただの実装詳細です Collectionがインデックスイテレータサブシーケンスにどの型を使うかは気にしませんただサポートされる型を使用するだけですしかし要素では話が違います Collectionがどの要素型を使うか常に気にすることはありませんが要素では制約や返還など何かする必要がありますほぼ全員のプロトコルユーザが気にかける要素のような型に関連する場合プロトコル名の後にカギ括弧を使ってそれに名前を付けプライマリ関連型にしますその後プロトコルのプライマリ関連型を any Collectionを含むプロトコルの名前を書ける場所ならどこにでもカギ括弧の構文で制約することができます一部の方はこの型を見てこう言うかもしれません「待てよ」「AnyCollectionというのがすでにあるじゃないか」 anyを大文字にして一緒に実行するだけなのか？」そのとおりです古いAnyCollectionは型消去ラッパーで any型と同じ目的を果たす手書きのstructですここでの違いはAnyCollection structは見たことがないくらい退屈で長いボイラープレートのコードで any型は組み込みの言語機能で基本的な機能を無料で果たします AnyCollection structは any型では完全に一致しない機能がまだあるため後方互換性のために残りますしかしコードに独自の型消去ラッパーがあるならボックス型やクロージャの代わりに組み込みのany型で再実装するか型エイリアスで置き換えてみてはどうでしょう Swiftでは any型が著しく向上されました anyキーワードが導入されたためどこで使用するか確認できますジェネリック引数にパスすることもできプロトコルでそれを使用する制限を廃止しましたさらにany型のプライマリ関連型を制約できるようになりましたしかしこれらのさまざまな改善が施されても any型にはまだ制限があります例えばMailmapがEquatableに適合した場合 any Mailmapsを使用することができますが等号演算子を一緒に使用することはできません等号演算子はmailmapsが同じ具象型が必要だからですしかしany Mailmapを２つ使用するとそれは保証されませんですのでany型はかなり改善されましたが機能とパフォーマンスの面でまだ重要な制限がありますなので多くの面で使用しない方がいいでしょう代わりにジェネリクスを使用してください addEntriesの２つのバージョンに戻りその知恵を適用してみましょうどちらのバージョンもまったく同じ動作をしますが上のものはジェネリック型を使用し下はany型を使用しますジェネリックバージョンはより効率的で機能性が高いためそちらを使用します any型は読み書きがより簡単なためそちらを使いたくなるでしょうジェネリックバージョンを書くには２つのジェネリック型の名前を宣言しどちらも制約し最後にパラメータ型としてこの名前を使用します「any Collection」や「any Mailmap」と書くよりも面倒ですなので欠点があってもanyを使いたくなりますしかしそれはハンマーの柄は握りやすいためスクリュードライバの代わりにハンマーを使うという私の先ほどの話と同じになりますその選択をする必要がないべきですそこでSwiftはジェネリックを any型と同じくらい使いやすくしましたジェネリックパラメータが使われているのが１ヶ所なら省略語としてキーワードを書くことができますプライマリ関連型もサポートされておりすべてのmailmapエントリのコレクションを理解しやすいコードで承認することができますそれがツールボックスにあるならジェネリクスを避ける必要はもうありませんジェネリクスとany型で選択肢があるならジェネリクスも同様に使いやすくなります「any」の代わりに「some」と書くだけですこの際作業に最適なツールを使うべきですプロトコルとジェネリクスについては大まかに説明しただけです詳細や Swiftのジェネリック機能のおさらいに関しては今年はもう２つトークがあります『Swiftのジェネリクスを活用する』と『Swiftでプロトコルインターフェイスを設計する』
Angelaと私は20件以上の Swiftの変更についてご紹介しましたしかしまだまだ他にも変更はありますすべての変更はピッチ提案評価され SwiftフォーラムのEvolution委員会で公的に承認されましたこれらすべてが形成され実現したのは Apple外部のコミュニティメンバーのおかげです皆さんもメンバーの一員なら Swift 5.7をすばらしいリリースにしてくれてありがとうございました次の変更に貢献したい場合は Swift.org/contributingで参加方法をご覧くださいありがとうございましたハッピーコーディング！
♪

@main struct MyPlugin: CommandPlugin {

    func performCommand(context: PluginContext, arguments: [String]) throws {
        let process = try Process.run(doccExec, arguments: doccArgs)
        process.waitUntilExit()
    }

}

8:34 - Build tool plugins

import PackagePlugin

@main struct MyCoolPlugin: BuildToolPlugin {
    func createBuildCommands(context: TargetBuildContext) throws -> [Command] {
        // Run some command
    }
}

8:39 - Implementing a build tool plugin

import PackagePlugin

@main struct MyCoolPlugin: BuildToolPlugin {
    func createBuildCommands(context: TargetBuildContext) throws -> [Command] {

        let generatedSources = context.pluginWorkDirectory.appending("GeneratedSources")

        return [
            .buildCommand(
                displayName: "Running MyTool",
                executable: try context.tool(named: "mycooltool").path,
                arguments: ["create"],
                outputFilesDirectory: generatedSources)
        ]
    }
}

9:23 - Module disambiguation with module aliases

let package = Package(
        name: "MyStunningApp",
        dependencies: [
            .package(url: "https://.../swift-metrics.git"),
            .package(url: "https://.../swift-log.git")
        ],
        products: [
            .executable(name: "MyStunningApp", targets: ["MyStunningApp"])
        ],
        targets: [
            .executableTarget(
                name: "MyStunningApp",
                dependencies: [
                    .product(name: "Logging", 
                             package: "swift-log"),
                    .product(name: "Metrics", 
                             package: "swift-metrics",
                             moduleAliases: ["Logging": "MetricsLogging"]),
  ])])

9:42 - Distinguishing between modules with the same name

// MyStunningApp

import Logging           // from swift-log
import MetricsLogging    // from swift-metrics

let swiftLogger = Logging.Logger()

let metricsLogger = MetricsLogging.Logger()

11:09 - Example set of protocols

public protocol NonEmptyProtocol: Collection
    where Element == C.Element, 
        Index == C.Index {
    associatedtype C: Collection
}

public protocol MultiPoint {
    associatedtype C: CoordinateSystem
    typealias P = Self.C.P

    associatedtype X: NonEmptyProtocol 
        where X.C: NonEmptyProtocol, 
            X.Element == Self.P
}

public protocol CoordinateSystem {
    associatedtype P: Point where Self.P.C == Self
    associatedtype S: Size where Self.S.C == Self
    associatedtype L: Line where Self.L.C == Self
    associatedtype B: BoundingBox where Self.B.C == Self
}

public protocol Line: MultiPoint {}

public protocol Size {
    associatedtype C: CoordinateSystem where Self.C.S == Self
}

public protocol BoundingBox {
    associatedtype C: CoordinateSystem
    typealias P = Self.C.P
    typealias S = Self.C.S
}

public protocol Point {
    associatedtype C: CoordinateSystem where Self.C.P == Self
}

13:14 - Memory safety in Swift

var numbers = [3, 2, 1]

numbers.removeAll(where: { number in
    number == numbers.count 
})

14:10 - Thread safety in Swift

var numbers = [3, 2, 1]

Task { numbers.append(0) } 

numbers.removeLast()

15:54 - A distributed actor player and a distributed function

distributed actor Player {
   
    var ai: PlayerBotAI?
    var gameState: GameState
    
    distributed func makeMove() -> GameMove {
        return ai.decideNextMove(given: &gameState)
    }
}

16:20 - A distributed actor call

func endOfRound(players: [Player]) async throws {
    // Have each of the players make their move
    for player in players {
        let move = try await player.makeMove()
    }
}

20:12 - Optional unwrapping

if let mailmapURL = mailmapURL {

    mailmapLines = try String(contentsOf: mailmapURL).split(separator: "\n")
    
}

20:29 - Optional unwrapping with long variable names

if let workingDirectoryMailmapURL = workingDirectoryMailmapURL {

    mailmapLines = try String(contentsOf: workingDirectoryMailmapURL).split(separator: "\n")
    
}

20:35 - Cryptic abbreviated variable names

if let wdmu = workingDirectoryMailmapURL {

    mailmapLines = try String(contentsOf: wdmu).split(separator: "\n")
    
}

20:46 - Unwrapping optionals in Swift 5.7

if let workingDirectoryMailmapURL {
  
    mailmapLines = try String(contentsOf: workingDirectoryMailmapURL).split(separator: "\n")

}

guard let workingDirectoryMailmapURL else { return }

mailmapLines = try String(contentsOf: workingDirectoryMailmapURL).split(separator: "\n")

21:07 - Closure type inference

let entries = mailmapLines.compactMap { line in

    try? parseLine(line)

}

func parseLine(_ line: Substring) throws -> MailmapEntry { … }

21:33 - Type inference for complicated closures

let entries = mailmapLines.compactMap { line in
    do {        
        return try parseLine(line)
    }
    catch {
        logger.warn("Mailmap error: \(error)")
        return nil
    }
}


func parseLine(_ line: Substring) throws -> MailmapEntry { … }

22:15 - Mismatches that are harmless in C...

// Mismatches that are harmless in C…
int mailmap_get_size(mailmap_t *map);
void mailmap_truncate(mailmap_t *map, unsigned *sizeInOut);

void remove_duplicates(mailmap_t *map) {
    int size = mailmap_get_size(map);
    size -= move_duplicates_to_end(map);
    mailmap_truncate(map, &size);
}


// …cause problems in Swift.
func removeDuplicates(from map: UnsafeMutablePointer<mailmap_t>) {
    var size = mailmap_get_size(map)
    size -= moveDuplicatesToEnd(map)
    mailmap_truncate(map, &size)
}

22:33 - Better interoperability with C-family code

func removeDuplicates(from map: UnsafeMutablePointer<mailmap_t>) {
    var size = mailmap_get_size(map)
    size -= moveDuplicatesToEnd(map)
    withUnsafeMutablePointer(to: &size) { signedSizePtr in
        signedSizePtr.withMemoryRebound(to: UInt32.self, capacity: 1) { unsignedSizePtr in
            mailmap_truncate(map, unsignedSizePtr)
        }
    }
}

23:41 - String parsing is hard

func parseLine(_ line: Substring) throws -> MailmapEntry {
    func trim(_ str: Substring) -> Substring {
        String(str).trimmingCharacters(in: .whitespacesAndNewlines)[...]
    }

    let activeLine = trim(line[..<(line.firstIndex(of: "#") ?? line.endIndex)])
    guard let nameEnd = activeLine.firstIndex(of: "<"),
          let emailEnd = activeLine[nameEnd...].firstIndex(of: ">"),
          trim(activeLine[activeLine.index(after: emailEnd)...]).isEmpty else {
        throw MailmapError.badLine
    }

    let name = nameEnd == activeLine.startIndex ? nil : trim(activeLine[..<nameEnd])
    let email = activeLine[activeLine.index(after: nameEnd)..<emailEnd]

    return MailmapEntry(name: name, email: email)
}

24:05 - String parsing is still hard with better indexing

func parseLine(_ line: Substring) throws -> MailmapEntry {
    func trim(_ str: Substring) -> Substring {
        String(str).trimmingCharacters(in: .whitespacesAndNewlines)[...]
    }

    let activeLine = trim(line[..<(line.firstIndex(of: "#") ?? line.endIndex)])
    guard let nameEnd = activeLine.firstIndex(of: "<"),
          let emailEnd = activeLine[nameEnd...].firstIndex(of: ">"),
          trim(activeLine[(emailEnd + 1)...]).isEmpty else {
        throw MailmapError.badLine
    }

    let name = nameEnd == activeLine.startIndex ? nil : trim(activeLine[..<nameEnd])
    let email = activeLine[(nameEnd + 1)..<emailEnd]

    return MailmapEntry(name: name, email: email)
}

24:20 - What's the problem?

let line = "Becca Royal-Gordon <beccarg@apple.com>       # Comment"

func parseLine(_ line: Substring) throws -> MailmapEntry {
    func trim(_ str: Substring) -> Substring {
        String(str).trimmingCharacters(in: .whitespacesAndNewlines)[...]
    }

    let activeLine = trim(line[..<(line.firstIndex(of: "#") ?? line.endIndex)])
    guard let nameEnd = activeLine.firstIndex(of: "<"),
          let emailEnd = activeLine[nameEnd...].firstIndex(of: ">"),
          trim(activeLine[activeLine.index(after: emailEnd)...]).isEmpty else {
        throw MailmapError.badLine
    }

    let name = nameEnd == activeLine.startIndex ? nil : trim(activeLine[..<nameEnd])
    let email = activeLine[activeLine.index(after: nameEnd)..<emailEnd]

    return MailmapEntry(name: name, email: email)
}

24:55 - Drawing a picture

"Becca Royal-Gordon <beccarg@apple.com>       # Comment"

/  space name space <      email      > space # or EOL /
/  \h* ( [^<#]+? )?? \h* < ( [^>#]+ ) > \h* (?: #|\Z)  /

25:10 - Swift Regex using a literal

func parseLine(_ line: Substring) throws -> MailmapEntry {

    let regex = /\h*([^<#]+?)??\h*<([^>#]+)>\h*(?:#|\Z)/

    guard let match = line.prefixMatch(of: regex) else {
        throw MailmapError.badLine
    }

    return MailmapEntry(name: match.1, email: match.2)
}

25:46 - Did a cat walk across your keyboard?
```
/\h*([^<#]+?)??\h*<([^>#]+)>\h*(?:#|\Z)/
```

26:34 - Regex builder

import RegexBuilder

let regex = Regex {
    ZeroOrMore(.horizontalWhitespace)
  
    Optionally {
        Capture(OneOrMore(.noneOf("<#")))
    }
        .repetitionBehavior(.reluctant)

    ZeroOrMore(.horizontalWhitespace)

    "<"
    Capture(OneOrMore(.noneOf(">#")))
    ">"

    ZeroOrMore(.horizontalWhitespace)
    ChoiceOf {
       "#"
       Anchor.endOfSubjectBeforeNewline
    }
}

27:05 - Turn a regex into a reusable component

struct MailmapLine: RegexComponent {
    @RegexComponentBuilder
    var regex: Regex<(Substring, Substring?, Substring)> {
        ZeroOrMore(.horizontalWhitespace)

        Optionally {
            Capture(OneOrMore(.noneOf("<#")))
        }
            .repetitionBehavior(.reluctant)

        ZeroOrMore(.horizontalWhitespace)

        "<"
        Capture(OneOrMore(.noneOf(">#")))
        ">"

        ZeroOrMore(.horizontalWhitespace)
        ChoiceOf {
           "#"
            Anchor.endOfSubjectBeforeNewline
        }
    }
}

27:30 - Use regex literals within a builder

struct MailmapLine: RegexComponent {
    @RegexComponentBuilder
    var regex: Regex<(Substring, Substring?, Substring)> {
        ZeroOrMore(.horizontalWhitespace)

        Optionally {
            Capture(OneOrMore(.noneOf("<#")))
        }
            .repetitionBehavior(.reluctant)

        ZeroOrMore(.horizontalWhitespace)

        "<" 
        Capture(OneOrMore(.noneOf(">#")))
        ">" 

        ZeroOrMore(.horizontalWhitespace)
        /#|\Z/
   }
}

27:39 - Use Date parsers within Regex builders

struct DatedMailmapLine: RegexComponent {
    @RegexComponentBuilder
    var regex: Regex<(Substring, Substring?, Substring, Date)> {
        ZeroOrMore(.horizontalWhitespace)

        Optionally {
            Capture(OneOrMore(.noneOf("<#")))
        }
            .repetitionBehavior(.reluctant)

        ZeroOrMore(.horizontalWhitespace)

        "<" 
        Capture(OneOrMore(.noneOf(">#")))
        ">" 

        ZeroOrMore(.horizontalWhitespace)

        Capture(.iso8601.year().month().day())

        ZeroOrMore(.horizontalWhitespace)
        /#|\Z/
   }
}

27:49 - Matching methods and strongly type captures in Regex

func parseLine(_ line: Substring) throws -> MailmapEntry {

    let regex = /\h*([^<#]+?)??\h*<([^>#]+)>\h*(?:#|\Z)/
    // or let regex = MailmapLine()

    guard let match = line.prefixMatch(of: regex) else {
        throw MailmapError.badLine
    }

    return MailmapEntry(name: match.1, email: match.2)
}

29:02 - A use case for protocols

/// Used in the commit list UI
struct HashedMailmap {
    var replacementNames: [String: String] = [:]
}

/// Used in the mailmap editor UI
struct OrderedMailmap {
    var entries: [MailmapEntry] = []
}

protocol Mailmap {
    mutating func addEntry(_ entry: MailmapEntry)
}

extension HashedMailmap: Mailmap { … }
extension OrderedMailmap: Mailmap { … }

29:26 - Using the Mailmap protocol

func addEntries1<Map: Mailmap>(_ entries: Array<MailmapEntry>, to mailmap: inout Map) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

func addEntries2(_ entries: Array<MailmapEntry>, to mailmap: inout Mailmap) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

31:05 - `Mailmap` and `any Mailmap`

func addEntries1<Map: Mailmap>(_ entries: Array<MailmapEntry>, to mailmap: inout Map) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

func addEntries2(_ entries: Array<MailmapEntry>, to mailmap: inout any Mailmap) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

31:17 - Improvements to `any` types

extension Mailmap {
    mutating func mergeEntries<Other: Mailmap>(from other: Other) { … }
}

func mergeMailmaps(_ a: any Mailmap, _ b: any Mailmap) -> any Mailmap {
    var copy = a
    copy.mergeEntries(from: b)
    return a
}

32:21 - More improvements to `any` types

protocol Mailmap: Equatable {
    mutating func addEntry(_ entry: MailmapEntry)
}

func addEntries2(_ entries: Array<MailmapEntry>, to mailmap: inout any Mailmap) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

32:54 - Using Collection as an `any` type

protocol Mailmap: Equatable {
    mutating func addEntry(_ entry: MailmapEntry)
}

func addEntries2(_ entries: any Collection<MailmapEntry>, to mailmap: inout any Mailmap) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

33:04 - Primary associated types

protocol Collection<Element>: Sequence {
    associatedtype Index: Comparable
    associatedtype Iterator: IteratorProtocol<Element>
    associatedtype SubSequence: Collection<Element>
                                    where SubSequence.Index == Index,
                                          SubSequence.SubSequence == SubSequence

    associatedtype Element
}

33:42 - Using primary associated types in Collection

func addEntries1<Entries: Collection<MailmapEntry>, Map: Mailmap>(_ entries: Entries, to mailmap: inout Map) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

func addEntries2(_ entries: any Collection<MailmapEntry>, to mailmap: inout any Mailmap) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

extension Collection<MailmapEntry> { … }

34:35 - Example of type erasing wrappers

struct AnySprocket: Sprocket {
    private class Base { … }
    private class Box<S: Sprocket>: Base { … }
    private var box: Base

    // …dozens of lines of code you hate
    // having to maintain…
}

34:38 - Replace boxes with built-in `any` types

struct AnySprocket: Sprocket {
    private var box: any Sprocket

    // …fewer lines of code you hate
    // having to maintain…
}

34:44 - Or try type aliases
```
typealias AnySprocket = any Sprocket
```

35:09 - `any` types have important limitations

protocol Mailmap: Equatable {
    mutating func addEntry(_ entry: MailmapEntry)
}

func areMailmapsIdentical(_ a: any Mailmap, _ b: any Mailmap) -> Bool {
    return a == b
}

35:44 - Using generic types vs. `any` types

func addEntries1<Entries: Collection<MailmapEntry>, Map: Mailmap>(_ entries: Entries, to mailmap: inout Map) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

func addEntries2(_ entries: any Collection<MailmapEntry>, to mailmap: inout any Mailmap) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

36:40 - `some Mailmap` and `any Mailmap`

func addEntries1<Entries: Collection<MailmapEntry>>(_ entries: Entries, to mailmap: inout some Mailmap) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

func addEntries2(_ entries: any Collection<MailmapEntry>, to mailmap: inout any Mailmap) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

36:50 - `some Mailmap` and `any Mailmap` with Collection and primary associated types

func addEntries1(_ entries: some Collection<MailmapEntry>, to mailmap: inout some Mailmap) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

func addEntries2(_ entries: any Collection<MailmapEntry>, to mailmap: inout any Mailmap) {
    for entry in entries {
        mailmap.addEntry(entry)
    }
}

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

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

リソース

関連ビデオ

WWDC22