Swift

Swift4基本構文_型的な何か

更新日:

Kotlinに超入門してみたので続いてSwiftに超入門してみる。
超入門に使用する書籍は以下。
[改定新版]Swift実践入門-直感的な文法と安全性を兼ね備えた言語 WEB+DB PRESS plus
Playgroundsを使って確認しながら各単元の何かを書いてみる。

変数と定数

変数はvar、定数はletで宣言する。Kotlinと同様に宣言時に型情報が決まる必要がある。
つまり、変数(定数)宣言時に型アノテーションを書くか、初期値の型から型推論させるか。
型推論が出来るので、右辺から型が決まる場合には左辺の型定義(型アノテーション)は省略可。

nilは代入不可。使用時までに値を入れている必要あり。

スコープ

外側の宣言は内側の宣言で使える。逆はできない。特別な予約語は不要。普通。

Bool型,リテラル

Bool型のリテラルはtrue,false。
演算子は論理和、論理積、否定のみ。普通。

Int型,リテラル

IntはInt8,Int16,Int32,Int64。
32bitプラットフォームでIntはInt32、64bitだとInt64。普通。

Float型,Double型,リテラル

32bitがFloat、64bitがDouble。
Float,Doubleは無限(isInfinite)と非数値(isNaN)という状態をStaticプロパティとして持つ。

異型間の代入

Swiftでは型が異なる変数同士の代入を暗黙的にできない。イニシャライザをかます。
縮小方向の代入は端数処理が行われる。

異型間の比較

Swiftでは型が異なる変数同士の比較ができない。イニシャライザをかます。
結構、型の違いにシビアなのか…。
Int32とInt64は比較できるみたい。FloatとDoubleはできない。

String型,リテラル

文字列リテラルはダブルクォーテーション。エスケープは一般的なやつが使える。
リテラル内での変数展開は\()演算子。${}の方がいいのに…。

kotlinでも見かけたスリーダブルクォート。これの発祥はPythonらしい。
面白いのがスリーダブルクォート内において変数自体のインデント分が無視されること。
kotlinのTrimよりも強烈。以下、sとrの出力は同じになる。

String.Index

StringとCharacterの関係も一般的。String内のCharacterを指す方法が用意されている。
String.startIndex(=0),String.endIndex(=文字数)を使ってCharacterを指す例。

Int型とString型の変換

イニシャライザを通す。変換できない場合はnilが入る。

文字列の結合

文字列の結合は+演算子。append(_:)も使える。

配列,配列リテラル

配列はArray。SyntaxSugarとして[Element]という書き方もできる。
配列リテラルは[]。同一型リテラルの配列から型推論可能。
順序数で要素にアクセス可能。
append(_:)で追加、insert(_at:)で挿入、remote(at:)で削除。

Dictionary型,リテラル

Key->Value辞書はDictionary、SyntaxSugerとして[Key:Value]という書き方もできる。
辞書リテラルは[“key1″:”value1″,”key2″:”value2”]のように書く。
同一型の辞書から型推論可能。

Keyは一意でないといけないので、Keyとして使える型には制限がつく。
DictionaryはDictionary。Key型はHashableプロトコル(インターフェース?)
に準拠したもの(Keyからハッシュ値を計算できる)のみ使える。
DictionaryへのアクセスはOptional(Value)を返す。つまり無いキーの値はnil。

更新,追加は同じ。存在するkeyを指定して値を代入すれば更新、存在しないkeyなら追加。
削除はnilを設定する。

範囲型

Swiftの範囲型は数学的なモデリングになってる。
1つ目は開区間、半開区間、閉区間。2つ目は順序(計数可能)。
数値以外の範囲についてもforループを回して順番に要素にアクセスできたりする。
範囲型が範囲を定義すると、範囲に収まる値が得られるのではなく、
区間と上限下限をもったオブジェクトのまま保持される。

Optional

型がnilを許容するか否か。Wrapped型がnilを許容する場合はOptional、許容しない場合はWrapped。
Suger Syntaxとして、OptionalをWrapped?と書くこともできる。

ぬるぽ防止(Unwrap)

デフォルトではOptional型同士の四則演算はできない。
明示的なアンラップ(Optional->Wrapped)が必要。
??演算子を使うと、左辺のOptional(Wrapped)がnilの場合に右辺、
nilでない場合にWrappedをアンラップして返す。
!演算子を使うと強制アンラップ。当然nilならぬるぽ。ぬるぽ時のエラーがドキッとする。
当然、強制アンラップは非推奨。

ぬるぽ防止(Optional chain)

Optionalの値を使うために必ずアンラップしないといけないとなると面倒。
?.演算子を使うと、nil、非nilの場合を1行に含めることができる。
左辺がnilである場合はnil、nilでない場合はOptional(Wrapped)を返す。
?.を数珠つなぎに書いていくと、最初のnilで評価が止まってそれ以降のnil参照を行わない。(なのでchain)

強制アンラップ構文

ぬるぽを恐れるあまり、nil可能なケースが面倒になっているのを和らげるためか、
何か迷いのようなものを感じるけれども、OptionalをWrapped?ではなくWrapped!と書くと、
型としてOptionalを維持したまま、暗黙的に強制アンラップしてから計算が行われる。
当然、nilが入っていればぬるぽで止まる。

アップキャスト

継承関係やプロトコル(インターフェース?)準拠により上位型の存在が確実な場合、
アップキャスト可能。アップキャストはas演算子。
確実な上位関係でない型へのアップキャストは実行時エラー。
アップキャストは暗黙的に実行可能。

ダウンキャスト

上位型から下位型へのキャスト。失敗のリスクがある。
失敗のリスクをOptionalで解決するのがas?演算子、リスクをケアしないのがas!演算子。
as?によるダウンキャストはOptionalを返す。as!はWrappedを返す。
as!が失敗した場合、実行時エラーが発生する。

-Swift
-

Copyright© ikuty.com , 2024 AllRights Reserved Powered by AFFINGER4.