---
title: Swift 3 その基本ルールを眺める #cswift
tags:  #swift #カジュアルswift勉強会  
author: [熊谷友宏](https://www.docswell.com/user/es_kumagai)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/47ZG26N3E3.jpg?width=480
description: そろそろ Swift 3.0 のことも整理しておきたいなと思って、まずは主に Swift 3 の展望と、言語の雰囲気を左右するガイドライン周りを調べてみました。  ※ Docswell での公開に移行する直前の Slideshare での閲覧数は 6,486 でした。
published: May 26, 16
canonical: https://www.docswell.com/s/es_kumagai/5V16X4-cswiftswift3-160526140515
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/47ZG26N3E3.jpg)

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


# Page. 2

![Page Image](https://bcdn.docswell.com/page/YJ6YV28Z7V.jpg)

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


# Page. 3

![Page Image](https://bcdn.docswell.com/page/GJ5GD299J4.jpg)

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


# Page. 4

![Page Image](https://bcdn.docswell.com/page/9E2Y8425ER.jpg)

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


# Page. 5

![Page Image](https://bcdn.docswell.com/page/D7YG6MY67M.jpg)

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


# Page. 6

![Page Image](https://bcdn.docswell.com/page/VENGZWR1J8.jpg)

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


# Page. 7

![Page Image](https://bcdn.docswell.com/page/Y79WZXMY73.jpg)

Late 2016


# Page. 8

![Page Image](https://bcdn.docswell.com/page/G78N12LKJD.jpg)

Swift 3
will be released sometime in late 2016


# Page. 9

![Page Image](https://bcdn.docswell.com/page/L7LPQ2LPJR.jpg)

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


# Page. 10

![Page Image](https://bcdn.docswell.com/page/4EM418M2JW.jpg)

何が変わったんだろう


# Page. 11

![Page Image](https://bcdn.docswell.com/page/PERWL5V5J9.jpg)

Swift 3
その概要を知りたい


# Page. 12

![Page Image](https://bcdn.docswell.com/page/P7XPWKZXJX.jpg)

調べ始めた⽮先


# Page. 13

![Page Image](https://bcdn.docswell.com/page/37KDV589ED.jpg)

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


# Page. 14

![Page Image](https://bcdn.docswell.com/page/LJ3RMK29E5.jpg)

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


# Page. 15

![Page Image](https://bcdn.docswell.com/page/8JDY63Z8JG.jpg)

Swift 3 概要


# Page. 16

![Page Image](https://bcdn.docswell.com/page/VEP6Y4DW78.jpg)

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


# Page. 17

![Page Image](https://bcdn.docswell.com/page/27V3GX19JQ.jpg)

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


# Page. 18

![Page Image](https://bcdn.docswell.com/page/5JG38V24EL.jpg)

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


# Page. 19

![Page Image](https://bcdn.docswell.com/page/47Q596PREP.jpg)

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


# Page. 20

![Page Image](https://bcdn.docswell.com/page/KE49X4YQJ1.jpg)

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


# Page. 21

![Page Image](https://bcdn.docswell.com/page/L71KN46LEG.jpg)

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


# Page. 22

![Page Image](https://bcdn.docswell.com/page/G7WD4XWQE2.jpg)

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


# Page. 23

![Page Image](https://bcdn.docswell.com/page/4JZG265373.jpg)

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


# Page. 24

![Page Image](https://bcdn.docswell.com/page/YE6YV29ZJV.jpg)

いずれにしても


# Page. 25

![Page Image](https://bcdn.docswell.com/page/GE5GD2N9E4.jpg)

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


# Page. 26

![Page Image](https://bcdn.docswell.com/page/972Y84557R.jpg)

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


# Page. 27

![Page Image](https://bcdn.docswell.com/page/DJYG6MK6JM.jpg)

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


# Page. 28

![Page Image](https://bcdn.docswell.com/page/V7NGZWZ1E8.jpg)

Swift 3.0 Developer Preview


# Page. 29

![Page Image](https://bcdn.docswell.com/page/YJ9WZXZYJ3.jpg)

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


# Page. 30

![Page Image](https://bcdn.docswell.com/page/GJ8N121KED.jpg)

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


# Page. 31

![Page Image](https://bcdn.docswell.com/page/LJLPQ2QPER.jpg)

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


# Page. 32

![Page Image](https://bcdn.docswell.com/page/47M41812EW.jpg)

API ガイドラインに倣う


# Page. 33

![Page Image](https://bcdn.docswell.com/page/P7RWL5L5E9.jpg)

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


# Page. 34

![Page Image](https://bcdn.docswell.com/page/PJXPWKWXEX.jpg)

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


# Page. 35

![Page Image](https://bcdn.docswell.com/page/3JKDV5V97D.jpg)

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


# Page. 36

![Page Image](https://bcdn.docswell.com/page/LE3RMKM975.jpg)

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


# Page. 37

![Page Image](https://bcdn.docswell.com/page/8EDY6368EG.jpg)

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


# Page. 38

![Page Image](https://bcdn.docswell.com/page/V7P6Y4YWJ8.jpg)

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


# Page. 39

![Page Image](https://bcdn.docswell.com/page/2JV3GXG9EQ.jpg)

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


# Page. 40

![Page Image](https://bcdn.docswell.com/page/5EG38V847L.jpg)

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


# Page. 41

![Page Image](https://bcdn.docswell.com/page/4JQ5969R7P.jpg)

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


# Page. 42

![Page Image](https://bcdn.docswell.com/page/K749X4XQE1.jpg)

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


# Page. 43

![Page Image](https://bcdn.docswell.com/page/LJ1KN4NL7G.jpg)

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


# Page. 44

![Page Image](https://bcdn.docswell.com/page/GJWD4X4Q72.jpg)

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


# Page. 45

![Page Image](https://bcdn.docswell.com/page/4EZG2623J3.jpg)

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


# Page. 46

![Page Image](https://bcdn.docswell.com/page/Y76YV2VZEV.jpg)

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


# Page. 47

![Page Image](https://bcdn.docswell.com/page/G75GD2D974.jpg)

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


# Page. 48

![Page Image](https://bcdn.docswell.com/page/9J2Y8485JR.jpg)

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


# Page. 49

![Page Image](https://bcdn.docswell.com/page/DEYG6M66EM.jpg)

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

JTVDDFTTPS


# Page. 50

![Page Image](https://bcdn.docswell.com/page/VJNGZ31178.jpg)

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

YBQQFOE Z 

QSJOU Y


# Page. 51

![Page Image](https://bcdn.docswell.com/page/YE9WZ95YE3.jpg)

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


# Page. 52

![Page Image](https://bcdn.docswell.com/page/GE8N19YK7D.jpg)

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


# Page. 53

![Page Image](https://bcdn.docswell.com/page/LELPQW4P7R.jpg)

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


# Page. 54

![Page Image](https://bcdn.docswell.com/page/4JM419K27W.jpg)

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

MJOFJOUFSTFDUT MJOF


# Page. 55

![Page Image](https://bcdn.docswell.com/page/PJRWLGX579.jpg)

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


# Page. 56

![Page Image](https://bcdn.docswell.com/page/PEXPWX6X7X.jpg)

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

1SPHSFTT3FQPSUJOH


# Page. 57

![Page Image](https://bcdn.docswell.com/page/3EKDVW19JD.jpg)

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


# Page. 58

![Page Image](https://bcdn.docswell.com/page/L73RM1Q9J5.jpg)

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


# Page. 59

![Page Image](https://bcdn.docswell.com/page/87DY6X987G.jpg)

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


# Page. 60

![Page Image](https://bcdn.docswell.com/page/VJP6YPZWE8.jpg)

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

TJO


# Page. 61

![Page Image](https://bcdn.docswell.com/page/2EV3G2W97Q.jpg)

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


# Page. 62

![Page Image](https://bcdn.docswell.com/page/57G38RD4JL.jpg)

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


# Page. 63

![Page Image](https://bcdn.docswell.com/page/4EQ59V1RJP.jpg)

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

ृᑰҶᆼཡӁӔҮӒҷ

NJO Y 
Z 
[ 


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

QSJOU Y 


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

TJO Y


# Page. 64

![Page Image](https://bcdn.docswell.com/page/KJ49XMRQ71.jpg)

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


# Page. 65

![Page Image](https://bcdn.docswell.com/page/LE1KN8QLJG.jpg)

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


# Page. 66

![Page Image](https://bcdn.docswell.com/page/GEWD4ZMQJ2.jpg)

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


# Page. 67

![Page Image](https://bcdn.docswell.com/page/47ZG21Q3E3.jpg)

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


# Page. 68

![Page Image](https://bcdn.docswell.com/page/YJ6YVL6Z7V.jpg)

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


# Page. 69

![Page Image](https://bcdn.docswell.com/page/GJ5GD169J4.jpg)

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


# Page. 70

![Page Image](https://bcdn.docswell.com/page/LE3RM1Q275.jpg)

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


# Page. 71

![Page Image](https://bcdn.docswell.com/page/8EDY6X96EG.jpg)

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


# Page. 72

![Page Image](https://bcdn.docswell.com/page/V7P6YP9ZJ8.jpg)

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


# Page. 73

![Page Image](https://bcdn.docswell.com/page/2JV3G2MMEQ.jpg)

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

[JQ TFRVFODF 
TFRVFODF


# Page. 74

![Page Image](https://bcdn.docswell.com/page/5EG38RGX7L.jpg)

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


# Page. 75

![Page Image](https://bcdn.docswell.com/page/4JQ59VX57P.jpg)

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


# Page. 76

![Page Image](https://bcdn.docswell.com/page/K749XM6VE1.jpg)

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


# Page. 77

![Page Image](https://bcdn.docswell.com/page/LJ1KN8V47G.jpg)

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


# Page. 78

![Page Image](https://bcdn.docswell.com/page/GJWD4ZLZ72.jpg)

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


# Page. 79

![Page Image](https://bcdn.docswell.com/page/4EZG21MLJ3.jpg)

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


# Page. 80

![Page Image](https://bcdn.docswell.com/page/Y76YVLNMEV.jpg)

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


# Page. 81

![Page Image](https://bcdn.docswell.com/page/G75GD15Q74.jpg)

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


# Page. 82

![Page Image](https://bcdn.docswell.com/page/9J2Y81NWJR.jpg)

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


# Page. 83

![Page Image](https://bcdn.docswell.com/page/DEYG6ZP9EM.jpg)

以上
Swift 3 の基本ルール


# Page. 84

![Page Image](https://bcdn.docswell.com/page/VJNGZ35D78.jpg)

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