そろそろ Swift 3.0 のことも整理しておきたいなと思って、まずは主に Swift 3 の展望と、言語の雰囲気を左右するガイドライン周りを調べてみました。

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

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

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

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

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

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

7. Late 2016

8. Swift 3
will be released sometime in late 2016

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

10. 何が変わったんだろう

11. Swift 3
その概要を知りたい

12. 調べ始めた⽮先

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

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

15. Swift 3 概要

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

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

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

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

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

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

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

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

24. いずれにしても

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

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

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

28. Swift 3.0 Developer Preview

29. 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 の⽬標に合う変更だけを採⽤
概要

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

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

32. API ガイドラインに倣う

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

63. 慣習的な指標
関数よりもメソッドやプロパティを使う
▶ 次のような場⾯でだけ、関数を使う

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

83. 以上
Swift 3 の基本ルール

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