Swiftの新機能

(音楽)

(拍手) おはようございます 今回のテーマはSwiftです SwiftとSwiftコミュニティは 進化しました スラヴァと私が 改良された点をご紹介します 主な議題は２つです まずはオープンソースと それに関連したコミュニティ 次にベータ版Xcode 10の Swift 4.2を詳しく紹介します

オープンソースの開発は GitHub上で行ってきました

ユーザ間で 議論や提案を重ねて 言語と基本ライブラリの 改良を行ってきました

600人以上のユーザが コードをGitHub上に提供し １万8000件以上の プルリクエストをマージ Swift.orgを開設してから SwiftはXcode用に ダウンロードが可能となり Ubuntuにも対応しています これは開発スナップショット および公式リリース日です

また全プラットフォームでの Swiftの使用を実現するには コミュニティによるテストの サポートが欠かせません Swiftサポートを広げるため 大勢が努力しています 我々も協力しました

継続的インテグレーション システムを拡大したのです 新たなプラットフォームで Swiftを使う時も ハードウェアサポートを プラグインしテストできます Swiftサポートを 広げる第一歩です

オープンソースの開発には 多額の投資も行いました 変更点について論じる コミュニティです コミュニティの要望で 約半年前にメール形式から― フォーラムに変えました ユーザが求めたのは 自分のレベルに合った 参加方法です 以前は困難でしたが フォーラムで可能となりました

フォーラムは 一般のプロジェクトでも 使えるようにしました

Swiftオープンソースの 管理者であれば フォーラムで議論が可能です 議題はユーザや 開発についてなど

Swift.orgの一般的な 利用方法も考えました 今週 The Swift Programming LanguageをSwift.orgに移しました URLはdocs.swift.orgで コミュニティで活用できる ドキュメントがあります

人々はSwiftを使うことに 心を躍らせていて― あちこちで話題です 例えばPodcastやMeetup カンファレンスなどを 活用して 評価などを参考にしています 昨年より我々は プレゼンテーションを行い Swiftの技術的な解説や 何が可能かを伝えてきました オープンソースの開発への 参加方法もです 情報の提供は 今後も続けていきます

その一環として 金曜にカンファレンスがあります try! Swift San Joseです コミュニティメンバーとの ワークショップがあり オープンソースの開発に 協力する人をサポートします コンパイラチームも参加し 議論の手助けをする予定です

コミュニティは以上です 次はSwift 4.2 まずは改良点と その影響に関して話します

Swiftの大規模アップデートは 年に２回です Swift 4.2は4.1と4.0からの アップデートです 大まかに２つの点が 改良されました １つは開発者の 生産性を重視した点 改良点は様々です 例えばビルド速度の向上 さらに力を入れたのが デバッガからエディタまでの 操作性の改善です コミュニティは 言語の改良にも注力し 開発者のワークフローを 改善しました またSDKの改良のため 投資も続けています Objective-C APIsが うまく反映され 言語やAPIの活用が より有効的になりました さらに 注力しているのが ランタイムの変更や改良による― バイナリ互換性の達成です 達成時期は―

Swift 5をリリース予定の 2019年初めです バイナリ互換性とは？ Swift 5以降のコンパイラで ビルドしたSwiftコードを バイナリレベルで別のコードと 相互に運用できることです 言語の成熟において 重大な進歩です これでSwiftのランタイムが OSに組み込まれ アプリケーションにバンドルで 含む必要がありません スタートアップの時間や メモリ使用量なども改善され 様々な好結果が得られます

ABIの安定化 つまり バイナリ互換性については Swift.orgのABI STABILITYを ご覧ください

Swift 4.2はSwift 5へと つながっていきます

ソース互換性の話をします Xcode 10には１つの Swiftコンパイラが含まれます Swift 4.2がそうです しかしXcode 9と同じく コンパイラは複数言語の 互換モードがあります どのモードでも APIや言語機能が― すべて使用可能です これらはソースに影響します

最初の２つは Xcode 9にも搭載され Swift 3と4のコードを変えず そのまま使うことができます さらにSwift 4.2ではSDKの 改良で幅が広がりました

そうです

前バージョンからの移行は Edit menuで対応できます SDKの変更に関して 注意点があります ベータ版Xcode 10では SDKが改良がされるため フィードバックを募集します APIで改良すべき点と Swiftへの影響などです 4.2への移行を先に行うと あとで変更があるので 移行を遅らせるのも １つの選択です

Swift 4.2ではコードの 発達が急速に進んでいます 言語の成熟において 重要な時期です だからこそSwift 3から Swift 4.2に移行を勧めます コードサイズは改善され 言語も発達しました Swift 3互換モードは Xcode 10で最後となります

ツールの話に移ります Xcode 9に比べ Swiftプロジェクトのビルドは 大幅に改善されました MacBook Proのクアッドコア Intel Core i7プロセッサです その中の１つを紹介します

Objective-Cで始まり Swiftを組み込んだ プロジェクトです これは普通の流れです ビルド時間の改善で Swiftコードのビルド速度が 大幅に向上しました Swiftコードの ビルド速度だけを見ると 以前の３倍の 速度になっています プロジェクト全体では 1.6xの高速化です

ビルドの改善は プロジェクトの内容や コード量とコア数などで異なります 大体のプロジェクトは 2xの速度になります さらなる利点があります Swiftでは複数の ファイルを扱えます ヘッダファイルは不要です コンパイラの 不要な処理も多いです そこでコンパイルパイプラインを 革新し 無駄を抑え コアの活用を効率化しました これが速さの理由です ビルドの工程に関しては 今週 別のセッションがあり 様々な利点について話します

さて１番の利点は デバッグビルドです

Xcodeのビルド設定を 例に説明します 最近 コンパイルモードを 最適化レベルから分けました プロジェクトの作成方法です リリースビルドは Whole Moduleモードで 全ファイルを 同時にビルドします これが最適化を可能にします 最適化の機会が 増えるということです デバッグビルドは Incrementalモードで ビルドが同時ではありません これにより パフォーマンスは低下します Optimazation Levelは No optimazationです デバッグ情報が改善します リリースビルドは 最適化されますが そのレベルは あとで説明します

コンパイルモードと 最適化レベルを分けたことで ある興味深い暫定策が 見つかりました Whole Moduleモードと No optimazationを組み合わせると デバッグビルドが 速くなるのです この組み合わせにより 先にお話しした無駄が 格段に抑えられるからです 除去に努めてきた 不要部分が大幅に減るのです しかしビルドが 増えにくくなり― １つを変えると 全ファイルが再構築されます Xcode 10の デバッグビルドでは 暫定策は必要なくなります Incrementalモードも 先の組み合わせと同じく効果的です すでにサポート 範囲内だからです

次にランタイムの 最適化についてです バイナリ互換性にも つながります

Swiftは自動で メモリを管理します Objective-Cと同様に 参照カウントを使います これはコンパイラの リリースまでの流れです Swift 4.1の場合です

+1 reference countが 付随します 規約ではオブジェクトが 別の関数に渡されると 関数が呼び出され リリースされました リリース処理を 別の関数にさせるのです これはオブジェクトの ライフタイムを縮めています 最小限の働きしかしません しかし こういったコードの場合 オブジェクトを異なるAPIに 何度も渡します 呼び出し規約に従い 初めの参照数が最後の 呼び出しとつり合います しかし規約では 途中の呼び出しが 保持されリリースされます 無駄な作業です オブジェクトは一連の 流れの中でも生きています Swift 4.2では改善しました オブジェクトは リリースされません 保持とリリースの 工程は消えました

これで無駄が縮小されました これによる利点は コードサイズが 縮小されたことと ランタイムの改善です

また文字列も改善しました 以前は24だったのが 今は16バイトです メモリと動作との間の 妥協点です まだこのサイズでも 文字列を最適化できます 文字列が15バイト内の場合 文字列の型として 表示されます 異なるバッファに 移す必要はありません これでメモリと動作が さらに改善されます 文字列内の最適化と同様に 多くの文字列を入力できます

最後に言語の 改良点をお話しします コードサイズの 縮小についてです

呼び出し規約を変え コードサイズを抑えました 最適化レベルも 追加しました Optimize for Sizeです ダウンロード制限など アプリケーションの容量が 重要な場合に有用です Swiftはプログラムの 静的知識を備えています コンパイラは 動作を最適化しやすく インライン展開や 脱仮想化など 動作の改善に 役立っています しかし時に それが不要な場合も

これはソース互換性に Osizeを適用した結果で GitHubのフレームワークと アプリケーションを含みます コードサイズが 10～30％縮小されました Swiftコードをコンパイルした 機械語のサイズで アプリケーション全体の サイズではありません

ランタイムは 約５％遅くなります 若干の損失ですね しかし支障はありません 使用の目的によります 興味があれば 試してみてください

次はスラヴァがSwift 4.2の 言語改善点をお話しします (拍手) スラヴァ･ペーストフです Swift 4.2の新しい言語の 特性について話します シンプルで 管理しやすくなりました

本題に移る前に まずは 言語改善の工程をお話しします Swiftはオープンソースで オープンデザインです もし言語改善の アイデアがあれば フォーラムに書き込みます アイデアが注目され 試案をまとめたら アイデアを実装し コアチームに提出できます 評価中もコミュニティで さらにフィードバックがあり チームが試案を 正式に受理するか決めます Swift Evolutionの ページでは Swift 4.2に追加された 試案のリストが閲覧できます 試案の数がとても多いので すべてはお話しできません しかし強調したいのは 多くの試案が コミュニティから 生まれたということです ユーザ間で共感できるような 言語の改善すべき点をあげ 解決方法のアイデアを 出し合います 皆さんの貢献で Swiftが改善されるのです いいですね (拍手) 最初の改良点は列挙型での ボイラープレートの削除です 例えば列挙型で データタイプのすべての値を printと定義します Swift 4では プロパティの定義で 全型のリストも含めました 新たな型を追加したら プロパティの更新が必要です でないと正確な 動作が得られません コンパイラに繰り返し 同じ作業を課すことになります そこでCaseIterable プロトコルが追加されました プロトコルを適合させれば コンパイラが全型を作ります 以上です (拍手) また別のボイラープレートも 削除しました ジェネリックコードを 作成できない場合です Swift 4の containsメソッドでは その数列の要素型が Equatableでなければ 要素は見つけられません 文字列がEquatableなので その配列でも呼び出せます 配列の配列内で呼び出すと 整数の配列では要素型の 同値比較はできません コンパイル時間エラーが出ます ではライブラリが全配列を Equatableとすればいい しかし それはいけません 配列の要素型が Equatableでない場合 配列をEquatableには できません

配列の要素型が Equatableならば 配列の同じ動作が定義でき 要素の比較が可能です ライブラリは この 限定的な適合ができます 要素型がEquatableなら 配列も同様になります Swift 4.2では今の例が 可能になりました

また他の限定的な適合を ライブラリで定義できます 例えばOptionalと DictionaryはEquatableです HashableやEncodable Decodableも適合します そして… (拍手) 今まで不可能だった 組み立てができます Optional整数値の 配列があれば すべてが可能になります

今週末のセッションでは 限定的な適合や総合的な 改良点を詳しくお話しします

次にEquatableとHashableの 定義について Swiftには多くのプロパティを持つ 構造体があり これらは すべてEquatableです ２つの値を比較するだけで 構造体もEquatableにします Swift 4では 手入力が必要でした ボイラープレートです プロパティを追加したら Equatableの更新も必要で その際に間違いが 起こりかねません Swift 4.1から同値比較の 実装が可能になりました 実装しなくても プロパティがEquatableならば コンパイラが 自動的に処理します Hashableも同様です ジェネリックタイプは？ これはleftとrightの インスタンスのデータ型です 両方をEquatableに 制限したくありません 関数やエラー non Equatableも 使用可能にするためです 限定的な適合を宣言し― 両方がそうなら それぞれもEquatableとします これだけではありません 同値比較の実装については 正しいやり方は１つです どちらの値も同じ型か確認し ペイロードが同等かを チェックします Swift 4.2ではコンパイラが この合成作業を行います Hashableも同様です

これで 例えば整数または 文字列のSetが持てます

さて… (拍手) 時に同値比較とハッシュ化を 手入力で行う場合があります

例を見てみましょう 都市を表す データがあるとします 都市名と州と人口が 情報としてあります この例での目的は１つ 都市名と州を同値比較します 同値であれば 人口のチェックは不要です もしコンパイラに 同値比較を実行させると 不要な人口の比較も してしまいます ここは手入力ができますし 簡単な作業です でもHashableは？

都市のハッシュコードを 計算する場合 都市名と州の ハッシュコードの計算と 結合が必要です そのやり方は？ 非等価演算も使えますし 演算式をネットで探したり 自分で考えたりもできます しかし どちらも最善策ではなく ハッシュ結合も 分かりにくい機能です うまく使えない場合の 損害は大きく DictionaryやSetの 動作プロパティには 高度なハッシュ機能が 求められます またセキュリティに関しても アタッカーがハッシュを すべて同値にしてしまい アプリケーションに 送るとします アプリケーションがDoS攻撃で 使用できなくなります Swift 4.2はより良い APIを導入しました Swift 4と4.1の Hashableプロトコルは １つのハッシュ値が １つの整数値を生成します Swift 4.2は プロトコルを改良し hash(into:) requirementを 加えました １つの値を 生成するのではなく インスタンスを取り出し 複数の値を与え ハッシュコードとして１つにします 都市データの例に戻りますと 都市名と州のhash(into:)を 再帰的に呼び出し― Hasherオブジェクトに インスタンスを渡します すると― ハッシュアルゴリズムが ハッシュコードの質と 動作を調整してくれます DoS攻撃の さらなる予防策として アプリケーション起動時には 乱数が使われます

最新の Hashableプロトコルを使えば コードの移行も 簡単なのでお勧めです １つだけ気をつけてください アプリケーションの実行間で ハッシュ値や要素の順序は 変わらないものと 期待するかもしれません しかし 乱数を使うので そうはならず― コード修正が必要です そのためビルド設定を加えました Swift Deterministic Hashingの 環境変数です スキームエディタで選び 乱数を一時的に無効にします

では乱数の生成について 話しましょう

現状のSwiftで生成する場合 インポートされた C APIを使います プラットフォーム間で 名前や特性が異なるため 理想的ではありません ビルド設定チェックが必要です しかし これらは低レベルで 実装が難しいのです 例えば１から６の 数値を得たい場合 Darwinのarc4randomが 使えます ６で割った余りを計算するのです しかし１から６で 均等な結果となりません Swift 4.2では新しいAPIを 導入し改善しました まず数値型は ランダムメソッドにより 範囲内で均等な数値を 返すようになりました さらに浮動小数も 扱えるのです

(拍手) Collectionプロトコルにも 確率要素を加えました 空のCollectionを渡した場合は null値が返されます 最後にshuffleメソッドです 対象のCollection要素の 乱数配列を可能にします

デフォルトのRandom Number Generatorを勧めますが それ以外でも構いません 乱数生成プロトコルに 適合する型を書き込めば APIに渡すことができ 乱数を生成する多重定義を 持つことができます

ビルド設定チェックについて もう少し詳しくお話しします

よくあるパターンです iOSとmacOSで利用できる Swiftコードがあります iOSでUIkitを使うとします macOSではAppKitを使います まずは“#if”でコンパイル時間 チェックを書き込み UIkitが使える OSをリストします 重要なのは どのOSで実行するかではなく UIkitのインポートです Swift 4.2では importビルド設定命令を加え より使いやすくしました (拍手) Swift 4.2の新機能で さらにコードを改善できます 例えばAppKitも チェックするとします UIkitもAppKitも 使えないような― 例えばLinuxの場合 “#error”ビルド命令を使い エラーメッセージを作ります

この次も ボイラープレートです シミュレータで 条件付きコンパイルをする時 Swift 4では すべてをコピー ペーストしなければなりません Swift 4.2では targetEnvironmentが使えます 目的を明確にし コンパイルしているのが― シミュレータなのか確認できます 同時に FIXMEを“#warning” ビルド命令に置き換え あとでFIXMEの修正を 忘れないようにします

これで大体 新しい 機能の話は終わりました 少しだけ別の話をします Implicitly Unwrapped Optionalに 関してです さて― Implicitly Unwrapped Optionalは 複雑です まずはメンタルモデルから 見ていきます どういうものか？ Swift 3より 式の型ではありません そうは考えません 代わりに宣言の属性だと 考えてください こういった宣言を まずコンパイラは― Optionalとして型検査します そこでつじつまが 合わない場合 アンラップ後 マークをして型検査します

例を見てみましょう 関数が２つあります Implicitly Unwrapped Optionalの整数と どんな型にも対応する値です １つ目の結果で ２つ目を呼び出します AnyにOptional整数値を 格納できるので 強制アンラップは不要です 値はOptionalになります

２つ目の例を見ましょう ここで１つ目の関数は… 間違えました ２つ目の関数は整数です 従って １つ目の結果で ２つ目を呼び出しても 整数のあるべき所に Optional整数値を渡せません コンパイラが 強制アンラップして 整数同士になるので 問題ありません

このメンタルモデルでImplicitly Unwrapped Optionalが説明できます しかし最近までモデルが 機能しない例外もありました 別の型のImplicitly Unwrapped Optionalは使えないからです Swift 4.2でも同じです Implicitly Unwrapped整数値の 配列は置けません しかしSwift 4で こんなケースがありました Implicitly Unwrapped整数値でも 型エイリアスを定義でき 配列を作ることができました しかしコンパイラの生成した コードは 複雑でした Swift 4.2では この機能を実装し直し メンタルモデルに 沿うようにしました ご覧のコードが コンパイル時間の警告を出力し Optionalの整数値として コンパイラが解析します 極端なケースなので 通常のコードには影響しません しかし気になるようであれば Swift.orgの ブログをご覧ください 変更された点について 詳しい解説が載っています

では最後の議題に移ります メモリへの 排他的チェックです Swift 4にもメモリの 排他的チェック機能がありました コンパイル時間と ランタイムのチェックです 特定の動作の実行が 制限されました 同じメモリを使っての 作業ができませんでした では例をご覧ください

OSパスのデータ型を 実装するコードです パスコンポーネントの 配列です withAppendedメソッドで 配列に要素を加えます クロージャを呼び出し 配列から要素を除きます コードはSwift 4でも 有効です しかし パスのデータ型を見ると パスが局所変数に 格納されています withAppendedを呼び出し クロージャ内の局所変数を 再度表示します どこに問題が？ コードが あいまいになっています クロージャ内の 局所変数にアクセスした時 withAppendedにより 数値が変更されています あいまいな点はこうです withAppendedで呼び出す前の パスの値を指すのか 変更されたあとの 現在値を指すのかです Swift 4ではコンパイル 時間エラーとされていました これを解消するには コンパイラに命令をします 新しい値が得たいなら クロージャにパラメータとして 渡すだけです

これを見てください ほぼ同じ機能ですが ジェネリックで― パラメータが戻り値の型です この場合も クロージャ内の パス値は同じくあいまいです Swift 4では このエラーを 察知できませんでした Swift 4.2では 排他的チェックを改善し この あいまいさを 察知します 別の解決策としては パラメータとしてクロージャに 渡しても修正可能です

この改善点に加えて リリースビルドにも 排他的チェックを追加しました パフォーマンスが重要でなければ 永続的な使用をお勧めします 今後 負荷が削減され 常に使えるレベルになれば さらなる保護機能として 役立つでしょう 配列範囲のチェックや 整数オーバーフローと同じです

今日お話しできなかったことも 多くあります

アプリケーションで 試してください 新たな機能を試し 質問があれば いつでも尋ねてください ありがとう (拍手)