EZ-NET 熊⾕友宏 http://ez-net.jp/

2016.05.21 カジュアル Swift 勉強会 #8

Swift 3 ?

Swift 3.0-dev

その基本ルールを眺める

横浜 iPhone 開発者勉強会#yidev

わいわい・ゆるく、iPhone 開発者のみんなで楽しく過ごすのが⽬的の会

【 横浜・⾺⾞道 】カジュアル Swift 勉強会

#cswift

ゆるくみんなで Swift を語らえる場を作りたくて始めた会

【 横浜・⻘葉台 】

第２４回を 2016-07-02 に開催⾒込み

勉強会

熊⾕友宏@es_kumagai EZ-NET http://ez-net.jp/

熊⾕友宏

Xcode 5 徹底解説 MOSA

Xcode 5 の全機能を徹底的に解説した本

OSX/iOS 系の歴史深い有料会員制の勉強会

紙版は絶版、電⼦書籍は販売中 2016-05-13 まさかの延期！

Xcode 7 でも役⽴つはず

@es_kumagai EZ-NET http://ez-net.jp/

書籍 / 登壇

熊⾕友宏

AKIBA.swift 第２回

Objective-C のキャストと Swift の型変換

そんな２つの性質の違いを 安全性の観点でざっくり眺めみる予定

@クラスメソッド株式会社さま2016-05-30 19:00 〜

SwiftとObjective-Cとの⽂法⽐較

@es_kumagai EZ-NET http://ez-net.jp/

CodePiece

iOS, OS X, Apple Watch アプリ

ソースコードを Twitter と Gist に同時投稿できる。

いつもの電卓

計算式も⾒える電卓アプリ。 watchOS 1 対応

⾳で再配達ゴッド

簡単操作で 再配達の申し込み。

EZ-NET IP Phone

iPhone でひかり電話を使う。 ⾃宅 LAN からの利⽤専⽤

熊⾕友宏@es_kumagai EZ-NET http://ez-net.jp/

CodePiece for OS X

勉強会を楽しむアプリ ソースコードを Twitter と Gist に同時投稿できる勉強会で知⾒をみんなと共有したい時とかに便利！

#cswift

Late 2016

Swift 3will be released sometime in late 2016

Swift 3 Developer Previewhas 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 対応

▶ 厳格なクロスプラットフォーム

▶ 型システムの再検証

▶ ジェネリクスを完成系へ

要所？

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

Swift 4？着地点？

いずれにしても

⽬標達成のためにはソース互換性の破壊も辞さない構え

Swift 3.0 and later姿勢

Swift 4 以降では破壊を最⼩限に抑えようとしているみたい？

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

Swift 4 or 5 or later？

▶ 完全なソースコード互換性

▶ ⾔語による並列処理のサポート

▶ C++ との相互運⽤

▶ 健全なマクロとコンパイル時評価

▶ 数値型間の暗黙変換

Swift 3.0 完成のために敢えて先送りした課題

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

利⽤するには

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

API ガイドラインに倣う

API ガイドラインに倣う趣旨

▶ 簡潔に綴られたガイドライン

▶ 素敵な API を書こう！

▶ Swift 3.0 ⾃⾝もガイドラインに沿って仕様変更

原則

API ガイドラインに倣う

原則コードが明瞭であること

▶ 実体は１つ定義し、繰り返し使う

▶ API をデザインすることは その利⽤を明確かつ簡潔にする

▶ 原則よりも、そのコンテキストで明快であるかを考える

原則 2/3簡潔さよりも明確さを⼤事に

▶ 最も少ない⽂字数で書くことが⽬標ではない

原則 3/3定義にドキュメントコメントを添える

▶ ドキュメントを書くとAPI デザインを洗練させる

▶ 簡単な⾔葉で説明できないならデザインが間違っているのかも

▶ ドキュメントを書くことを先送りしないこと

名前付け

API ガイドラインに倣う

名前付け明確な⽤途を表現

▶ 名前を使う⼈やコードを読む⼈から曖昧性を排除

名前付け無駄な⾔葉の排除

▶ すべての⾔葉が明確な意味を含んでいること

名前付け役割に沿った名前にする (1/2)

▶ 変数、引数、付属型の名前は型ではなく役割に着⽬して決める

名前付け役割に沿った名前にする (2/2)

▶ 変数、引数、付属型の名前が型との結びつきが強ければ Type を付ける

名前付け弱い型情報を補う

▶ NSObject, Any, AnyObject, Int, String, …型で意図が伝えきれないときは⾔葉で補う

淀みない利⽤のために

API ガイドラインに倣う

淀みない利⽤のために英⽂法のフレーズを意識する (1/2)

▶ メソッドや関数の名前は、英⽂法のフレーズで使えることが好しい

淀みない利⽤のために英⽂法のフレーズを意識する (2/2)

▶ ただし、その名前の中⼼にないものは滑らかに読めなくても許容範囲

淀みない利⽤のためにファクトリーメソッド

▶ ファクトリーメソッドの名前はmake で始める

淀みない利⽤のために名前から最初の引数を除くケース

▶ イニシャライザとファクトリーメソッドは名前に最初の引数を含めない

淀みない利⽤のために⾃⾝への副作⽤を考慮した名前 (1/5)

▶ 副作⽤を伴わない場合は名詞的な名前

淀みない利⽤のために⾃⾝への副作⽤を考慮した名前 (2/5)

▶ 副作⽤を伴う場合は命令的な動詞の名前

淀みない利⽤のために⾃⾝への副作⽤を考慮した名前 (3/5)

▶ Nonmutating の名前が動詞的ならそれを過去形 “ed” にする

淀みない利⽤のために⾃⾝への副作⽤を考慮した名前 (4/5)

▶ Nonmutating の名前が動詞でも過去形だと不⾃然なときは “ing” にする

淀みない利⽤のために⾃⾝への副作⽤を考慮した名前 (5/5)

▶ Nonmutating の名前が名詞のときMutating の名前は先頭に “form” を付与

淀みない利⽤のために真偽値を返すときの名前

▶ 真偽値を返すプロパティやメソッドはその主張が読み取れるように表現

淀みない利⽤のためにプロトコルの名前 (1/2)

▶ プロパティが “それが何か” を表すなら名詞として読める名前にする

淀みない利⽤のためにプロトコルの名前 (2/2)

▶ プロパティが “能⼒” を表すなら“able” や “ible”, “ing” を最後につける

淀みない利⽤のためにその他

▶ これまで以外の、型、プロパティ、変数、定数、これらの名前は名詞にする

専⾨⽤語を使うとき

API ガイドラインに倣う

専⾨⽤語を使うとき原則

▶ 普通の⾔葉で的確に表現できるなら専⾨⽤語の使⽤は避ける

▶ 専⾨⽤語を使う場合は確⽴された意味にこだわる

▶ 専⾨⽤語を使わなければ曖昧になり、かつ、使うことで正確になる場合に使う

▶ 略語も、専⾨⽤語に等しい

専⾨⽤語を使うとき前例に従う

▶ その専⾨⽤語が⽂化的に適切ならわざわざ普通の⾔葉に置き換えない

慣習的な指標

API ガイドラインに倣う

慣習的な指標計算型プロパティの複雑さを表記

▶ プロパティの複雑性が O(1) 以外ならドキュメントコメントに明記する

▶ プロパティは複雑な計算をしない、そんな思い込みを抹消する

慣習的な指標関数よりもメソッドやプロパティを使う

▶ 次のような場⾯でだけ、関数を使う

慣習的な指標⼤⽂字と⼩⽂字の慣習

▶ 型とプロトコル名は⼤⽂字で始まるキャメルケース

▶ それ以外のすべては⼩⽂字で始まるキャメルケース

慣習的な指標頭字語 (1/2)

▶ すべてを⼤⽂字で表記する頭字語は全部を⼤⽂字か⼩⽂字で統⼀する

慣習的な指標頭字語 (2/2)

▶ 先頭だけを⼤⽂字で表記する頭字語は普通のキャメルケースで扱う

慣習的な指標同じ名前を使うとき (1/3)

▶ 近いドメインでは、同じ意味を持つ場合だけ同じ名前を使う

▶ 遠いドメインであれば問題にならない

慣習的な指標同じ名前を使うとき (2/3)

▶ 近いドメインで、異なる意味を持つなら同じ名前は避ける

慣習的な指標同じ名前を使うとき (3/3)

▶ 戻り値のオーバーロードは型推論で曖昧性を⽣むので避ける

慣習的な指標内部引数名を選ぶとき

▶ ドキュメントとしてきれいな名前を選ぶ

▶ ⽂法として成り⽴たない名前は避ける

慣習的な指標引数の既定値の使いどころ (1/2)

▶ 多くの場合に同じ値を渡す引数で既定値を使い、可読性を⾼める

慣習的な指標引数の既定値の使いどころ (2/2)

▶ メソッドファミリーよりも有⽤

▶ 同じ機能であることが苦なく読み取れる

慣習的な指標引数ラベルを除外するとき (1/6)

▶ 引数を区別できないときは外部引数名を除外する

慣習的な指標引数ラベルを除外するとき (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 ガイドラインに倣う

✓ 原則 ✓ 名前付け ✓ 淀みない利⽤のために ✓ 専⾨⽤語を使うとき ✓ 慣習的な指標 ✓ 特別な指⽰