アプリ開発の旅（一）：摩訶不思議なSwift

説明

なぜJavaScriptではないのかと聞かれることがありますが、それはスクリプト言語であり、型システムなどがなく、Swiftとは比較にならないからです。

私はフロントエンド開発者で、C、Java、Python言語については入門レベルの理解しかありませんが、TypeScript（以下TS）の機能と使用に関しては上級レベル（自負）です。そのため、私が驚く点が、他の方々にとっては「ただの当たり前の言語機能」に思えたり、「TypeScriptの設計者は天才なのか？」と感じられるかもしれません。

私はSwiftとTSの違いすべてに無理に驚くわけではありません。なぜなら、一部の違いはTS自身の不足によるものであり、またコンピュータ言語では一般的な設計（例えば数字をIntとDoubleで区別し、Number型だけにしないなど）もあるからです。驚くべきはJSの設計（結局1週間で急いで設計されたものです）であって、Swiftではありません。

私の考えでは、言語のルールや例外、予約語が多すぎる場合、それは良い言語とは言えません。

はじめに

この記事はSwiftの公式言語紹介の順番に沿って驚きを記述しており、驚かなかったり理解できない内容（例：附加宏）は省略しています。

基本知識

コメント

驚きポイント：XCodeには`/** */`ブロックコメントのショートカットがなく、`cmd + /`の行コメントしかありません。

VSCodeのブロックコメントショートカットも押しにくく、Alt + Shift + Aです。この機能はあまり使われていないのでしょうか？

もちろん、VSCodeとXCodeどちらも、/**と入力してEnterを押すと、自動的にブロックコメントが生成されます。

オプショナルバインディング

驚きポイント：デバッグ中に`if`文で常に`true`となる値をテスト用に書こうとしてもできません。`if`文のオプショナルバインディングは、必ずオプショナル型の値でなければなりません。

1

if let a = 2 { } // 错误！

こんな必要ある？

コレクション型

驚きポイント：配列メソッドの中で、`sort` はその場でソートを行うのに対し、`sorted` は新しい配列を返します。

一つの言語がフレームワークの仕事までこなすとは、さすがAppleのスタイルだ。これに類する驚きは他にもたくさんあるが、いちいち驚いている場合ではない。

制御フロー

if式

驚きポイント：`if-else`で同じ変数に代入する場合に対処するため、`if`式の書き方が用意されています。同様に、`switch`にも式形式が存在します。

Swiftはやりすぎなところがある：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// 平平无奇的写法
let a = 25
let str: String
if a <= 0 {
    str = "小"
} else if a >= 30 {
    str = "大"
} else {
    str = "中"
}
// 简写法
let str = if a <= 0 {
  "小"
} else if a >= 30 {
  "大"
} else {
  "中"
}

Switchのすごい判定

驚きポイント：switchには暗黙のフォールスルーがない

しかしこれは理解できるし、より合理的だ。普通の人が、わざわざ break を書かずに case 1 から case 2 に自動的に進んでほしいと思うだろうか？

驚きポイント：switchはオブジェクトの値を判定できる！

これは実際には feature であり、直感的により合理的で、まさにプロフェッショナル向けだ。

TSでは、switchのcase文が全等(===)判定を使用するため、通常switchの括弧内にオブジェクトを渡すことはない。オブジェクトは参照を判定するものであり、TSではオブジェクトの等価性を判定する必要がある場面は稀で、ましてやswitch文で判定することはまずない。

しかしSwiftでは、case文で判定する値を「キャプチャ」できる（正式名称は「パターン」と呼ばれる）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

let somePoint = (1, 1) // 一个平平无奇的元组罢了
// 我现在，开 始 判 断：
switch somePoint {
case (0, 0):
    print("\(somePoint) 在原点")
case (_, 0): // 忽略第一个值
    print("\(somePoint) 在 x 轴")
case (0, _): // 忽略第二个值
    print("\(somePoint) 在 y 轴")
case (-2...2, -2...2): // 判断元组的两个值是否分别在给定区间，在就匹配成功
    print("\(somePoint) 在盒子内部")
default:
    print("\(somePoint) 在盒子外部")
}

// 还可以值绑定！
switch somePoint {
case (let x, 0): // 匹配第二个值，捕获第一个值
    print("x轴值：\(x)")
case (0, let y): // 匹配第一个值，捕获第二个值
    print("y 轴值：\(y)")
case (let x, let y): // 兜底，因为 x 和 y 都是 let，还可以写作 case let (x, y)
    print("\(x) 和 \(y)")
}
// 还可以加 where 限定：
case let (x, y) where x == y:
//还可以多个匹配
case "a", "b", "c":

TSにおいても「複数マッチ」がサポートされていますが、Swiftのcaseにおける複数マッチとは全く異なることに注意が必要です。

Swiftの複数マッチでは、カンマ区切りの内容のいずれかが一致すればcase文が実行されます。しかし、TSのカンマ区切りのマッチは、本質的に最後の項目のみにマッチします。これはTSにおけるカンマ区切りの文が最後の値のみを返すためです：

1
2
3
4
5

var a = "d"
switch (a) {
 case "d", "c", "b":
  console.log("OK")// 此处不会执行，因为此 case 匹配 "b" 
}

関数

関数のラベル付き引数

驚きのポイント：仮引数（ラベル付き引数）は同名でも良い？？？さらに規定（また制限が来た、参った）：可変引数の後ろの引数は必ず引数ラベルが必要（もし1つだけなら実引数が仮引数になる）省略できない。

1
2
3
4
5
6
7

// 下面两个 a 标签参数，完全合法（因为是 label 无所谓）
// 而且 a b 后面的参数 a c（或者单独的一个参数）必须存在，不能用 _ 省略，
//  也可以理解，要不咋知道是第二个参数，而不是前面的可变参数来的？
func a (a b: Double..., a c: Double) -> Double {
    return b.reduce(0, +) + c
}
a(a: 1, 2, 3, 4, 5, a: 6)

クロージャ

クロージャのN種類の省略記法

驚きポイント：クロージャのシンタックスシュガーが多すぎてここでは全て列挙しませんが、最も衝撃的なのはたった1つの `>` 記号だけで表現できる形式です。

このように書ける本質的な理由は、String型に > という名前の関数が存在するからです。そうです、記号も関数になり得るのです！この点については後ほどさらに驚くべき内容を紹介します。

1
2

var num = ["9", "2", "1"]
var sortedNum = num.sroted(by: >)

本当に信じられない。

returnの省略

驚きのポイント：「単一行のreturnは省略可能」と理解できるかもしれないが、「複数行でもreturnを省略できる」ことは絶対に理解できないでしょう

TypeScriptにおけるreturnの省略は、Swiftの通常の書き方と同じで、単一行のreturn省略：

1
2
3
4
5
6

// 省略写法
var a = () => 2
// 正常写法是：
var a = () => {
 return 2
}

通常のSwift構文：

1
2
3

func a()-> Int {
 2 // -> 因为单行，所以省略了 return
}

しかし！SwiftUIでの書き方：

1
2
3
4

VStack {
 Text("Hello")
 Text("World")
}

驚くべきことに、これもトレーリングクロージャ関数です。VStackは関数であり、クロージャパラメータが最後かつ唯一のパラメータとして渡されるため、VStackの括弧を省略できます。しかし！ここでは2つのText関数呼び出しを返しているのに、returnが書かれていません。なぜでしょうか？

それはViewBuilderを使用しているからです。この仕組みは後述するresultBuilderと同じシンタックスシュガーです。

自動クロージャ

驚きポイント：一見普通のクロージャ代入に過ぎないようですが、その遅延評価能力には驚かされました。

自動クロージャについて最初に学んだ時、この例で「遅延評価」能力について説明されました：

1
2
3
4
5
6
7
8
9
10

var customersInLine = ["Chris", "Alex", "Ewa", "Barry", "Daniella"]
print(customersInLine.count)
// 打印 “5”
let customerProvider = { customersInLine.remove(at: 0) }
print(customersInLine.count)
// 打印 ”5“
print("Now serving \(customerProvider())!")
// 打印 “Now serving Chris!”
print(customersInLine.count)
// 打印 “4”

これはごく普通のクロージャーで、TSと同じくcustomerProvider変数がクロージャーに代入されているだけだと私は考えます。同じ実装をTSで書くとこうなります：

1
2
3

let customerProvider = () => {
 // 省略逻辑
}

そしてもちろん、それが呼び出されたときに初めてクロージャーのロジックが実行されます。これこそ遅延評価というものです！

しかし、その遅延評価の真価が発揮されるのは、クロージャーが引数として渡される場合です。

ごく普通の明示的なクロージャー呼び出しは、TSの呼び出し方法とほぼ同様で、クロージャーを引数として受け取り、書き方も中括弧の中に記述します：

1
2
3
4
5
6

// customersInLine 是 ["Alex", "Ewa", "Barry", "Daniella"]
func serve(customer customerProvider: () -> String) {
    print("Now serving \(customerProvider())!")
}
serve(customer: { customersInLine.remove(at: 0) } )
// 打印 “Now serving Alex!”

しかし、customerProvider を @autoclosuer とマークすると状況が変わります。この場合、serve 関数の呼び出しは次のように記述できます:

1
2
3
4
5
6

// customersInLine 是 ["Ewa", "Barry", "Daniella"]
func serve(customer customerProvider: @autoclosure () -> String) {
    print("Now serving \(customerProvider())!")
}
serve(customer: customersInLine.remove(at: 0))
// 打印 “Now serving Ewa!”

最後の serve 関数の呼び出しに注目してください。その引数 customer は文 customersInLine.remove(at: 0) です。TSでは、どんな場合でも呼び出しスタックはまずこの値を評価してから serve 関数を呼び出します。しかしSwiftでは、この書き方は上記の形式と単に見た目が異なるだけで、ロジックは同じです。つまり、まず serve 関数が実行され、その後内部でこの文が実行されます（customerProvider が呼び出された時点で）。これこそが噂の「遅延評価」というものでしょう。

このようなケースを多く書いていると、以下のようなコードに頻繁に出くわすことになります：

1
2

a(b.remove(2))
c(d.add4())

ここでは、括弧内の文が先に実行されるのか、外側の関数が先なのか判断が難しい場合があります。そのため、Swiftの公式ドキュメントでも以下のように説明されています：

自動クロージャを過度に使用すると、コードの可読性が低下する可能性があります。コンテキストや関数名は、計算が延期されていることを明確に示す必要があります。

本当に信じられない、推奨されていないなら最初から設計すべきじゃなかったのに！

列挙型

驚きポイント: 他の言語では単なる状態判断のためのオプション的な型に過ぎない列挙型が、Swiftでは最もよく使われる第一級の型であり、Structの機能を一部置き換えることができるなんて信じられますか？

驚きポイント2： 列挙型は値型です。

TypeScriptにおける列挙型はごく普通の「列挙型」にすぎず、単に値を列挙するだけで、主に状態マシンで状態を記述するために使用されます：

1
2
3
4

enum A {
 B = "B"
 C = "c"
}

もちろん、TSが提供する様々な機能には、実行時とコンパイル時の違いなどもありますが、ここでは触れません。TSでは、列挙型の代わりに完全にオブジェクトを使用することができます：

1
2
3
4
5
6
7
8
9

const enum A {
  B = 0,
  C = 1,
}

const A = {
  B: 0,
  C: 1,
} as const;

関連値

驚きポイント: Swiftのこの列挙型設計、一体何を考えてるの！

Swiftにおいて、列挙型の重要性は最優先です。すべてのケースを列挙可能（CaseIterableプロトコルに準拠が必要）、ケースを関数として扱い、呼び出し時に値を渡して列挙型インスタンスに処理させることができます。これを「関連値」と呼びます：

1
2
3
4

enum A {
 case b(Int, Int) // 声明方式好像一个协议（也就是抽象类）
 case c(String)
}

そして使用時に値を渡すことができます：

1

let a = A.b(1024, 9527)

列挙型が最もよく使われるのはswitch文の中です。驚くべきswitchと同様に驚くべきcaseを組み合わせて、次のように書くことができます：

1
2
3
4
5
6

switch a {
case .b(let d, let f):
 print("A.b 关联值为:\(d) 和 \(f)")
case let .c(g): // 上面提到的另一种 switch case 写法
 print("A.c:\(g)")
}

最初に見た時、正直かなり抽象的で、実際の使用場面も想像できませんでした（私自身そんなことをしたことがなかったので）。

暗黙的な代入

驚きポイント: 列挙型の型宣言は、列挙型自体の型（キーと値のペア）ではなく、ケースの型を宣言している。

Swiftにおける暗黙的な代入は、TypeScriptやその他のC系言語と同様で、最初の数字がnであれば、その後の値はn+1となります。

しかしSwiftはさらに一歩進んでいて、宣言した型に基づいて暗黙的に値を代入します。デフォルトでは行われません。例えば：

1
2
3
4
5
6

enum A: Int { // <- 声明了 Int 类型，所以隐式赋值了
 case b, c, d // b c d 分别为 0 1 2(需要使用 A.b.rawValue 才能访问，这又是另一个震惊点了）
}
enum B: String { // <- 声明了 String 类型，所以隐式赋值了
 case bb, cc, dd // bb cc dd分别为 "bb" "cc" "dd"
}

TSでは、Swiftで指定できるInt型（実際にはcaseの型を指す）さえ指定できず、enumの型（通常はRecordで別途定義されたキーバリューペア）しか指定できません。

構造体とクラス

衝撃の事実：構造体が値型だって？？？

この一見しっかり者の構造体が、実は値型（パフォーマンス最適化のためにImmutableの仕組みを使用）だったとは：

1
2
3
4

struct a {
 var b: Int
 var c: String
}

波括弧付きのもの、どう見ても値には見えない！信じられない！驚き！

プロパティ

様々なxxプロパティ/ラッパー/オブザーバー

驚きポイント：Swiftがやりすぎている。計算プロパティ、ストアドプロパティ、プロパティラッパー（TSにもある）、プロパティオブザーバー（TSにもあり、ラッパーと一緒）といった概念は、通常フレームワークが提供するものだ。例えばVueの`computed`や`watch`など。しかしSwiftはStructとクラスの中でこれらを自前で実装している。信じられない！

1
2
3
4
5
6

struct A {
 var b = 2 // <- 存储属性，直接有值，在 struct 实例化的时候就确定了
 var c: Int {
  return b * 2 // <- 一个只读计算属性，不存储值，因为单行，return 可以省略
 }
}

なお、属性ラッパーはグローバル変数には使用できません。

サブスクリプト

驚きポイント: これについては特に言うことはありません。「サブスクリプト」という概念自体が既に驚きで、コレクション、リスト、ディクショナリの要素にアクセスするためのショートカットを提供しています。さらに、サブスクリプトは関数のように複数の値を渡すこともできます。

基本的に、サブスクリプトの呼び出し方法は、データ構造（前述のコレクション、リスト、ディクショナリ）に対する関数呼び出しで値をアクセスすると考えられますが、違いは関数呼び出しが () を使用するのに対し、サブスクリプトは [] を使用することです。

継承

驚きポイント: これまでのすべての驚きポイントと同様に、Swiftはさまざまな目的や効果を実現するために、あたかも随意にキーワードを追加しているかのようです。そのため、継承に関連する予約語（もちろん、「予約語」と呼べるものではありません。Swiftでは予約語もすべて使用可能で、バッククォートで囲めば良いのです。これについては後ほど驚きポイントとして取り上げます）が数多く存在します。例えば: `final`、`override`、`open`、`required` など。

初期化プロセス

Structのメンバーワイズイニシャライザ

驚きポイント: Structは値型であるため、従来のClassのイニシャライザルールとは初期化時に違いがあります。

本来、StructとClassはどちらもごく普通のデータ構造で、TSのClassと何ら変わりません。しかし、Swiftはここでも一風変わったことをしています。

Structは値型であるため、特別な点として「メンバーワイズイニシャライザ」と呼ばれる初期化形式があります。これは、Structに init が全く定義されていない場合、そのプロパティを初期化するために引数を渡す形式でinitでき、明示的に記述する必要がないというものです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// 此 Struct 没有 init，因此适用逐一成员构造器
struct A { 
 var a: Int
 var b: Int
}
// 上述效果等同于：
struct A {
 var a: Int
 var b: Int
 init(a: Int, b: Int) {
  self.a = a
  self.b = b
 }
}
// 上面两个都可以这么用：
A(a: 1, b: 2)

しかし、このルールはClassには適用されません。Classは明示的にinitコンストラクタメソッドを持ち、プロパティを初期化する必要があります。

クラスの指定イニシャライザとコンビニエンスイニシャライザ

驚きポイント: え？イニシャライザには2種類あるの？？？

クラスの指定イニシャライザは、TSにおける通常のconstructと同じ役割を持つinitメソッドです。しかし、そのコンビニエンスイニシャライザは…initの前にconvenienceキーワードを付ける（また来た！）ものです:

1

convenience init() {}

実はここでSwiftのドキュメントは、なぜ便利イニシャライザが必要なのかを明確に読者に伝えず、直接クラスの初期化、継承プロセスとイニシャライザのデリゲーションについて説明しています。ここで初心者の方々に、なぜ便利イニシャライザというものが存在するのかを説明します。とてもシンプルな理由です：クラス内の複数の指定イニシャライザは互いに呼び出し合うことが許されていません。これだけの理由です。呼び出したくてたまらない？初期化プロセスを簡素化したい？それなら便利イニシャライザを使いなさい！

通常の書き方：

1
2
3
4
5
6
7
8
9
10
11

class A {
 var b: Int
 var c: String
 init(b: Int, c: String) {
  self.b = b
 }
 init() {
  self.b = 0
  self.c = "UnKnown"
 }
}

上記のように、self.b を2回書くのは面倒だと感じませんか？そこで、2番目の init() では、このようにしたいと考えています：

1
2
3

init() {
 self.init(b: 0, c: "UnKnown")	
}

コンパイラエラーが報告されました：Designated initializer for 'A' cannot delegate (with 'self.init'); did you mean this to be a convenience initializer?

この場合、convenienceイニシャライザを使用する必要があります：

1
2
3

converience init() {
 self.init(b: 0, c: "UnKnown")	
}

「便利」が目的です～

失敗可能イニシャライザ

驚きポイント: イニシャライザが失敗することもある？

実は、失敗可能イニシャライザとは、初期化プロセス（init関数の呼び出しプロセス）でエラーが発生する可能性があるものを指します。

したがって、イニシャライザがエラーを投げる場合、TSのように外側でtry-catchする必要はなく、直接明示すればよいです。方法はinitの後に疑問符を付けてinit?とし、エラーが発生する可能性のある場所でnilを返し、インスタンス化時にnilかどうかを判断するだけです。

Swiftでは通常のイニシャライザは値を返しません。これはTSと同じです——ただしTSのイニシャライザは値を返すことができ、返される値がオブジェクト型の場合、thisオブジェクトを置き換えます。これはさらに驚きかもしれません。

オプショナルチェーン

驚きポイント: Q: どのような場合に関数に()を書いているのに実行されない？A: オプショナルチェーンのシナリオです。

余計な説明は抜きにして、例を見てみましょう:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

func A() -> Int {
    print("OK")
    return 1
}
class B {
    var c: C?
}
class C {
    var d: Int?
}
var d = B()
// 震惊的事情发生了：
// 这里，A 函数未执行，不会打印 OK，赋值也不会成功，因为 c 是 nil，这个语句返回 nil（通常 Swift 的赋值语句都返回 Void 的，也就是空元组）
// 返回 nil 意味着你可以使用 if-let 语句判断
d.c?.d = A()

エラー処理

驚きポイント：列挙型と同様に、Swiftのtry-catch（実際はdo-catch）の設計は非常に複雑です。

catch文は任意のエラーをキャッチできるだけでなく、特定のエラータイプもキャッチ可能で、isを使用したりswitch文のように複数のcatch分岐でマッチングが行えます。これは驚きです：

1
2
3
4
5
6
7

do {
 try someError()
} catch is ErrorA {
 // xxx
} catch ErrorB, ErrorC, ErrorD.a {
 // xxx
}

並行処理

驚きポイント：ドキュメントを読んでいた時、最初は `withTaskGroup` が Group Task を行う組み込みメソッドだとは気づきませんでした。。。

await の使い方は TS の await と全く同じで、快適です！

拡張機能

驚きポイント：拡張機能はおそらく Swift で最も強力な設計です。組み込みオブジェクトでもサードパーティ製でも、どんなオブジェクトでも、自由に、低コストで、複雑な宣言やキーワードを一切必要とせずに拡張できます。

TS では既存のクラスを拡張する場合、プロトタイプチェーンを操作し、オブジェクトの this をそのクラスに向ける必要があります。

しかし Swift では、単に extension を書くだけで、好きなメソッドやプロパティを自由に追加できます。それらの this はインスタンスを指すか、拡張型（つまり静的）メソッドやプロパティになります。

まさに圧倒的な自由度です。

プロトコル

驚きポイント：プロトコルは Struct の抽象化問題を解決するために導入されたと思います。どの言語でもクラス自体は継承可能（言い切りすぎかもしれませんが）なので、余計な「プロトコル」を実装する必要はなく、抽象クラスで十分です。ただ副次的に、Swift はクラスの単一継承を制限すると同時に、プロトコルをクラス、Struct、列挙型のすべてで活用できるようにしました。

これ以上言うことはありません。言いたいことは上記に尽きます。

ジェネリクス

驚きポイント：ジェネリクスには「関連型」という概念があり、これは宣言時に付与するジェネリクスと同様の役割ですが、より強力です。

Swift のジェネリクス関連型は次のようなものです：

1
2
3
4
5
6

protocol Container {
    associatedtype Item
    mutating func append(_ item: Item)
    var count: Int { get }
    subscript(i: Int) -> Item { get }
}

なぜこのように設計されていないのか：

1
2
3
4
5

protocol Container<Item> {
    mutating func append(_ item: Item)
    var count: Int { get }
    subscript(i: Int) -> Item { get }
}

おそらく、この項目が非常に長くなり、エレガントでなくなる可能性があるためでしょう。例えば：

1
2
3
4

protocol SuffixableContainer: Container {
    associatedtype Suffix: SuffixableContainer where Suffix.Item == Item
    func suffix(_ size: Int) -> Suffix
}

名前の後ろに書くと、ジェネリック宣言が頻繁に画面からはみ出してしまい、非常に扱いづらい。

不透明型とカプセル化プロトコル

驚くべき点：コンパイラには型が何であるかを知らせつつ、呼び出し側には具体的な型を知らせず、ただそれが特定のプロトコルに準拠していることだけを知らせる効果を実現できます。

基本的に、不透明型とカプセル化プロトコルが実現しようとしている効果は、一方で呼び出し側に実装詳細を隠蔽しつつ、コードをリファクタリングする際に多くの変更を必要としないようにすることです。例えば：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

protocol Shape {
    func area() -> Double
}

struct Circle: Shape {
    var radius: Double
    func area() -> Double {
        return .pi * radius * radius
    }
}

func makeShape() -> some Shape {
    return Circle(radius: 5)
}

ここで、makeShapeが返す型は、Shapeプロトコルに準拠する任意の型であればよく、明示的にCircle型を返す必要はありません。このようにすることで、後からShapeに準拠する新しいStructを追加しても、この関数はそれを返すことができます（これはSwiftUIでよく使われる方法でもあります。例えばsome Viewなど）。

メモリ安全性

驚きのポイント：Swiftは値の参照渡しが可能なため、同じメモリ領域への同時読み書きが発生する可能性があります（これは理にかなっていますよね？）

1
2
3
4
5

var a = 1
func add(_ b: inout Int) {
    b += a
}
add(&a)

上記の実行はエラーを発生させますが、コンパイラは警告を出しません。このようなケースは多く存在するため、特に注意が必要です。TSには参照渡しの概念が存在しないため、このような問題は発生せず、簡単です～

高度な演算子

驚きのポイント: 記号を関数名として使用した関数を再定義/カスタマイズすることで、同じクラスや構造体のインスタンス間で相互操作を実現できます。

例を挙げます:

1
2
3
4
5
6
7
8
9
10
11

struct A {
 var b = 1
 var c = 2
 static func +(left: A, right: A) -> A {
  return A(b: left.b + right.b, c: left.c + right.c)
 }
}
// 然后你就可以
let a = A()
let b = A()
let c = a + b // <- 是的你没看错，struct 实例可以相加！

このデザインは素晴らしい、どうして思いつかなかったんだろう。すごいすごい。

注意が必要なのは、演算子メソッドには独自の属性があることです。例えば、+ は二項演算子であり中置演算子でもあるため、2つの関数を受け取ります。- は中置演算子（二項演算子）にも、前置演算子（単項演算子、func の前に prefix を追加する必要あり）にもなるため、オーバーロード可能です。

しかしSwiftでは、代入演算子 = はオーバーロードできず、三項条件演算子（a ? b : c）も同様にオーバーロード不可と規定されています。

この演算子は非常に一般的で、任意のSwift組み込みオブジェクト/Foundationオブジェクトにおいて、== のような等価判定の演算子関数を見かけることができます。

さらに、独自の演算子を実装することさえ可能です！

1
2
3
4
5
6
7
8
9
10
11

// 需要先声明，这是一个操作符，因为有两个值在操作符，所以这是个中缀操作符(infix)
infix operator +++++++
// 然后扩展一下整数类型
extension Int {
    static func +++++++(left: Int, right: Int) -> Int {
        return (left + right) * 7 // <- 因为有 7 个 + 号，所以我写了乘以 7
    }
}
// 这么用：
2 +++++++ 7 // <- 63

すごい。

結果ビルダー

驚きポイント：Swiftは「エレガントさ」と「再利用性」のために手段を選ばない。

以下のコードを見栄え良くするために、Swiftは@resultBuilderという魔法のようなものを「発明」しました。例：

通常の書き方：

1
2
3
4
5
6
7
8
9

var a = 1
var b = 2

struct A {
 var a: Int
}

// 这里会有一个三元判断
var c = A(a: a > b ? 666 : 999 )

Swiftは、上記の三項演算子による判定が煩雑で、複雑な条件分岐の場合にはコードが長くなり可読性が低下すると指摘し、よりエレガントな解決策を求めました。そこで生まれたのが（私の理解が正しければ）結果ビルダーです：

1
2
3
4
5
6
7
8
9
10
11
12

@resultBuilder
struct BBuilder {
    static func buildBlock(_ b: Int) -> Int { // 对应 if/else 分支的执行结果
        return b
    }
    static func buildEither(aaa: Int) -> Int { // 对应 if 分支
        return aaa
    }
    static func buildEither(bbb: Int) -> Int { // 对应 else 分支
        return bbb
    }
}

そして、上記の c 変数に次のように値を代入します：

1
2
3
4
5
6
7
8
9
10
11

func BB(@BBuilder b: () -> Int) -> A {
    return A(a: b())
}
// 终于等到 c 了，这里的 c 和最开始的 c 完全一样
var c = BB {
    if a > b {
        return 666
    } else {
        return 999
    }
}

再利用、エレガント、効率的、最高！

字句構造

驚きのポイント：Swiftには予約語が非常に多いにもかかわらず、予約語を識別子として使用することが許可されています。

方法は、バッククォートで囲むだけです：

1
2
3

func `func`() {} // <- 一个叫做 `func` 的函数
// 调用也是 
`func`()

しかし、キーワードを除けば、x と x は同じ変数です。

• 前の記事
  デュアルブートシステム間で同じショートカットキーを使う方法
• 次の記事
  CusorでiOSアプリを開発しリアルタイムでプレビューする方法