Swift 3 その基本ルールを眺める #cswift

Swift 3 ? その基本ルールを眺める 2016.05.21 カジュアル Swift 勉強会 #8 EZ-NET 熊⾕友宏 Swift 3.0-dev http://ez-net.jp/

• http://ez-net.jp/

熊⾕友宏 @es_kumagai EZ-NET http://ez-net.jp/ 勉強会 横浜 iPhone 開発者勉強会 カジュアル Swift 勉強会 【 横浜・⾺⾞道 】 #yidev 【 横浜・⻘葉台 】 #cswift わいわい・ゆるく、iPhone 開発者の みんなで楽しく過ごすのが⽬的の会 ゆるくみんなで Swift を語らえる場を 作りたくて始めた会 第２４回を 2016-07-02 に開催⾒込み

熊⾕友宏 @es_kumagai EZ-NET http://ez-net.jp/ 書籍 / 登壇 Xcode 5 徹底解説 MOSA Xcode 5 の全機能を 徹底的に解説した本 OSX/iOS 系の歴史深い 有料会員制の勉強会 Xcode 7 でも役⽴つはず ๏ਓձһ΋ଟ਺ 紙版は絶版、電⼦書籍は販売中 2016-05-13 まさかの延期！

熊⾕友宏 @es_kumagai EZ-NET http://ez-net.jp/ AKIBA.swift 第２回 SwiftとObjective-Cとの⽂法⽐較 @クラスメソッド株式会社さま 2016-05-30 19:00 〜 Objective-C のキャストと Swift の型変換 そんな２つの性質の違いを 安全性の観点でざっくり眺めみる予定 IUUQDMBTTNFUIPEDPOOQBTTDPNFWFOU

熊⾕友宏 @es_kumagai EZ-NET http://ez-net.jp/ iOS, OS X, Apple Watch アプリ CodePiece いつもの電卓 ソースコードを Twitter と Gist に同時投稿できる。 計算式も⾒える電卓アプリ。 watchOS 1 対応 ⾳で再配達ゴッド EZ-NET IP Phone 簡単操作で 再配達の申し込み。 iPhone でひかり電話を使う。 ⾃宅 LAN からの利⽤専⽤

CodePiece for OS X 勉強会を楽しむアプリ ソースコードを Twitter と Gist に同時投稿できる 勉強会で知⾒をみんなと共有したい時とかに便利！ Ͱ͖Δ͜ͱ #cswift

Late 2016

Swift 3 will be released sometime in late 2016

Swift 3 Developer Preview has been released on May 12, 2016

何が変わったんだろう

Swift 3 その概要を知りたい

調べ始めた⽮先

＿人人人人人人人人人＿ ＞ 突然の着地点変更 ＜ ￣Y^Y^Y^Y^Y^Y^Y^Y^Y￣

Swift 3.0 リリース達成のためなら 優先度を⾒極め、軌道修正も辞さない姿勢

Swift 3 概要

Swift 3.0 トップニュース？ ▶ 2016 年の後半にリリース ▶ Swift 2 からの破壊的な仕様変更

Swift 3.0 ⽬標 ▶ Swift ⾔語を確定・熟成させる ▶ Swift 3 以降でのソースコードの 互換性を⽬指す（努⼒⽬標） ▶ Swift 3 以降のソース互換破壊は 最⼩限の影響での実現を⽬指す

Swift 3.0 要所 ▶ API ガイドラインに倣う ▶ Objective-C や C のコードを Swift ⽂化に合わせて取り込む ▶ ⾔語を洗練 ▶ コンパイラや IDE の品質向上 ▶ Swift パッケージマネージャー

Swift 3.0 着地点 ⾔語の安定化を図り 他環境への移植性を⾒据える

Swift 4？ 概要 もしくは Swift 3.x かも

Swift 4？ ⽬標？ ▶ Binary Interface の安定化

Swift 4？ 要所？ ▶ ABI を安定化し Binary 互換レベルの向上を図る ▶ Fragile binary interface 対応 ▶ 厳格なクロスプラットフォーム ▶ 型システムの再検証 ▶ ジェネリクスを完成系へ

Swift 4？ 着地点？ 異なるバージョンでの Binary 互換と 他環境への移植性を確⽴

いずれにしても

Swift 3.0 and later 姿勢 ⽬標達成のためには ソース互換性の破壊も辞さない構え Swift 4 以降では破壊を最⼩限に抑えようとしているみたい？

Swift 5？ もしくは Swift 3.x とか 4.x かも

Swift 4 or 5 or later？ Swift 3.0 完成のために敢えて先送りした課題 ▶ 完全なソースコード互換性 ▶ ⾔語による並列処理のサポート ▶ C++ との相互運⽤ ▶ 健全なマクロとコンパイル時評価 ▶ 数値型間の暗黙変換

Swift 3.0 Developer Preview

Swift 3.0 Developer Preview 概要 ▶ Developer Preview 1 解禁 2016/05/12 (swift-3.0-preview-1) ▶ 4〜6 週間を⽬標に次の Preview へ ▶ 最終版は swift-3.0-branch を予定 ▶ Swift 3.0 向けの更新は、随時 master ブランチに取り込まれる ▶ 3.0 の⽬標に合う変更だけを採⽤

Swift 3.0 Developer Preview 利⽤するには A. Trunk Development をダウンロード https://swift.org/download/ B. master ブランチからビルド（最新） https://github.com/apple/swift

• https://swift.org/download/
• https://github.com/apple/swift

Swift 3 もう少し細かく眺める

API ガイドラインに倣う

API ガイドラインに倣う 趣旨 ▶ 簡潔に綴られたガイドライン ▶ 素敵な API を書こう！ ▶ Swift 3.0 ⾃⾝も ガイドラインに沿って仕様変更 IUUQTTXJGUPSHEPDVNFOUBUJPOBQJEFTJHOHVJEFMJOFT

API ガイドラインに倣う 原則

原則 コードが明瞭であること ▶ 実体は１つ定義し、繰り返し使う ▶ API をデザインすることは その利⽤を明確かつ簡潔にする ▶ 原則よりも、そのコンテキストで 明快であるかを考える

原則 2/3 簡潔さよりも明確さを⼤事に ▶ 最も少ない⽂字数で 書くことが⽬標ではない

原則 3/3 定義にドキュメントコメントを添える ▶ ドキュメントを書くと API デザインを洗練させる ▶ 簡単な⾔葉で説明できないなら デザインが間違っているのかも ▶ ドキュメントを書くことを 先送りしないこと

API ガイドラインに倣う 名前付け

名前付け 明確な⽤途を表現 ▶ 名前を使う⼈やコードを読む⼈から 曖昧性を排除

名前付け 無駄な⾔葉の排除 ▶ すべての⾔葉が 明確な意味を含んでいること

名前付け 役割に沿った名前にする (1/2) ▶ 変数、引数、付属型の名前は 型ではなく役割に着⽬して決める

名前付け 役割に沿った名前にする (2/2) ▶ 変数、引数、付属型の名前が 型との結びつきが強ければ Type を付ける

名前付け 弱い型情報を補う ▶ NSObject, Any, AnyObject, Int, String, … 型で意図が伝えきれないときは⾔葉で補う

API ガイドラインに倣う 淀みない利⽤のために

淀みない利⽤のために 英⽂法のフレーズを意識する (1/2) ▶ メソッドや関数の名前は、 英⽂法のフレーズで使えることが好しい

淀みない利⽤のために 英⽂法のフレーズを意識する (2/2) ▶ ただし、その名前の中⼼にないものは 滑らかに読めなくても許容範囲

淀みない利⽤のために ファクトリーメソッド ▶ ファクトリーメソッドの名前は make で始める YNBLF*UFSBUPS

淀みない利⽤のために 名前から最初の引数を除くケース ▶ イニシャライザとファクトリーメソッドは 名前に最初の引数を含めない

淀みない利⽤のために ⾃⾝への副作⽤を考慮した名前 (1/5) ▶ 副作⽤を伴わない場合は名詞的な名前 YEJTUBODF UP
Z
JTVDDFTTPS

淀みない利⽤のために ⾃⾝への副作⽤を考慮した名前 (2/5) ▶ 副作⽤を伴う場合は命令的な動詞の名前 YTPSU
YBQQFOE Z
QSJOU Y

淀みない利⽤のために ⾃⾝への副作⽤を考慮した名前 (3/5) ▶ Nonmutating の名前が動詞的なら それを過去形 “ed” にする

淀みない利⽤のために ⾃⾝への副作⽤を考慮した名前 (4/5) ▶ Nonmutating の名前が動詞でも 過去形だと不⾃然なときは “ing” にする

淀みない利⽤のために ⾃⾝への副作⽤を考慮した名前 (5/5) ▶ Nonmutating の名前が名詞のとき Mutating の名前は先頭に “form” を付与

淀みない利⽤のために 真偽値を返すときの名前 ▶ 真偽値を返すプロパティやメソッドは その主張が読み取れるように表現 YJT&NQUZ
MJOFJOUFSTFDUT MJOF

淀みない利⽤のために プロトコルの名前 (1/2) ▶ プロパティが “それが何か” を表すなら 名詞として読める名前にする $PMMFDUJPO

淀みない利⽤のために プロトコルの名前 (2/2) ▶ プロパティが “能⼒” を表すなら “able” や “ible”, “ing” を最後につける &RVBUBCMF
1SPHSFTT3FQPSUJOH

淀みない利⽤のために その他 ▶ これまで以外の、型、プロパティ、 変数、定数、これらの名前は名詞にする

API ガイドラインに倣う 専⾨⽤語を使うとき

専⾨⽤語を使うとき 原則 ▶ 普通の⾔葉で的確に表現できるなら 専⾨⽤語の使⽤は避ける ▶ 専⾨⽤語を使う場合は 確⽴された意味にこだわる ▶ 専⾨⽤語を使わなければ曖昧になり、 かつ、使うことで正確になる場合に使う ▶ 略語も、専⾨⽤語に等しい

専⾨⽤語を使うとき 前例に従う ▶ その専⾨⽤語が⽂化的に適切なら わざわざ普通の⾔葉に置き換えない "SSBZ
TJO

API ガイドラインに倣う 慣習的な指標

慣習的な指標 計算型プロパティの複雑さを表記 ▶ プロパティの複雑性が O(1) 以外なら ドキュメントコメントに明記する ▶ プロパティは複雑な計算をしない、 そんな思い込みを抹消する

慣習的な指標 関数よりもメソッドやプロパティを使う ▶ 次のような場⾯でだけ、関数を使う 
ृᑰҶᆼཡӁӔҮӒҷ
NJO Y
Z
[

ृᑰҶѬఙ✂ӘӔҮԠԏԵՒԫԗӘӒҷ
QSJOU Y

⁠ᇰӘ௻㍭ӕҴҮӐ␼▋ҿӶӉⷭ⅁ӘӒҷ
TJO Y

慣習的な指標 ⼤⽂字と⼩⽂字の慣習 ▶ 型とプロトコル名は ⼤⽂字で始まるキャメルケース ▶ それ以外のすべては ⼩⽂字で始まるキャメルケース

慣習的な指標 頭字語 (1/2) ▶ すべてを⼤⽂字で表記する頭字語は 全部を⼤⽂字か⼩⽂字で統⼀する

慣習的な指標 頭字語 (2/2) ▶ 先頭だけを⼤⽂字で表記する頭字語は 普通のキャメルケースで扱う

慣習的な指標 同じ名前を使うとき (1/3) ▶ 近いドメインでは、 同じ意味を持つ場合だけ同じ名前を使う ▶ 遠いドメインであれば問題にならない

慣習的な指標 同じ名前を使うとき (2/3) ▶ 近いドメインで、異なる意味を持つなら 同じ名前は避ける

慣習的な指標 同じ名前を使うとき (3/3) ▶ 戻り値のオーバーロードは 型推論で曖昧性を⽣むので避ける

慣習的な指標 内部引数名を選ぶとき ▶ ドキュメントとしてきれいな名前を選ぶ ▶ ⽂法として成り⽴たない名前は避ける

慣習的な指標 引数の既定値の使いどころ (1/2) ▶ 多くの場合に同じ値を渡す引数で 既定値を使い、可読性を⾼める

慣習的な指標 引数の既定値の使いどころ (2/2) ▶ メソッドファミリーよりも有⽤ ▶ 同じ機能であることが苦なく読み取れる

慣習的な指標 引数ラベルを除外するとき (1/6) ▶ 引数を区別できないときは 外部引数名を除外する NJO OVNCFS
OVNCFS
[JQ TFRVFODF
TFRVFODF

慣習的な指標 引数ラベルを除外するとき (2/6) ▶ Full-width な変換イニシャライザーは 最初の引数ラベルを除外する

慣習的な指標 引数ラベルを除外するとき (3/6) ▶ Narrowing な変換イニシャライザーは 最初の引数ラベルを除外しない

慣習的な指標 前置詞を伴うときの名前付け ▶ 前置詞を名前に含め、 最初の引数ラベルは除外しない

慣習的な指標 名前と最初の引数が⽂法的につながらないとき ▶ 最初の引数ラベルは除外しない

慣習的な指標 そのほか ▶ それ以外のすべての引数ラベルは 除外しない

API ガイドラインに倣う 特別な指⽰

特別な指⽰ クロージャーやタプルを API で扱うとき ▶ ラベル名をつけ、タプル利⽤時や ドキュメント記載時の可読性を向上

慣習的な指標 オーバーロードにおける曖昧性の排除 (1/2) ▶ 引数が何にも束縛されない場合、 オーバーロードの意味が曖昧になる可能性

慣習的な指標 オーバーロードにおける曖昧性の排除 (2/2) ▶ 意味が曖昧にならないよう、 ２つ⽬のオーバーロードにラベルを付与 ▶ ドキュメントともマッチするところに注⽬

以上 Swift 3 の基本ルール

Swift 3? まずは基本ルールを眺める 1. Swift 3 概要 (Swift 4, 5, …) 2. Swift 3.0 Developer Preview 3. API ガイドラインに倣う ✓ 原則 ✓ 名前付け ✓ 淀みない利⽤のために ✓ 専⾨⽤語を使うとき ✓ 慣習的な指標 ✓ 特別な指⽰