iOS8 と Swift

良い点とかとか。

オブジェクトの型をセーフする目的で Optional という概念が導入。

• オブジェクトが空の場合に起こりうる諸問題が解決できる

名前空間(名前の衝突が起こらないように記述できる概念)のようなものを用いることができる。

• 具体的には、NestedType を利用する方法と、モジュールを利用する方法の2通りの方法で実現できる。

実装時に使う型を指定できるジェネリクスという機能が導入されました。

• Java 経験者は馴染み深い

あれれと思う点。

動的な処理が Swift だけでは一切できない

• [NSObject performSelector:] の類と NSInvocation が Swift からは一切呼び出せません。使おうとすると怒られます。
  objc/runtime.hは試していませんが、同様に直接 Swift 経由では呼び出せず間にObjective-Cをかます必要があるのではないかと思われます。

@optionalなprotocolが限定的にしか使用できない

• 具体的には @objc属性を付けないと使えません。しかしこのような後方互換性のためだけに存在する属性をいつまでも Apple がサポートするかは疑問が残るということと、
  もう一つ以下の様な問題があります。

@objc属性のついたSwiftの型はただのObjective-Cクラスになる

• こういう問題があるのであまり使いたいとは思えません。
  ちなみに Cocoa のクラスはほぼすべて @objc属性が付いているためそれを継承して使うことになるアプリでは、
  事実上 Swift 本来の能力を出せないと思っていますが、実際のところはわかっていない。

メモリ管理が必要

• Swift のメモリ管理は GC ではなく ARC でありただの参照カウント方式にすぎない。Swift でも循環参照が発生しないようにプログラマが明示的に参照の種類を指定しなければいけない。
  その上 Objective-C で存在した strong / weak に加え unowned という新しい種類のメモリ管理が追加。
  これはweakが参照消滅し nil になる挙動であるため Optional型を使わなければならないのに対し、
  unowned は参照消滅しても nil にならない代わりに通常の型がそのまま使えるという。

closureでselfをキャプチャするときの循環参照対策が相変わらず必要

• Swift は delegate よりも closure を使った callback のほうが言語構造上向いているため closure を大量に使うことになると思うのですが、
  このとき self が closure を強参照し closure が self をキャプチャするようなコードを書いてしまうと循環参照になるためメモリが解放されなくなる問題が引き続き発生。
  対策として closure capture list と呼ばれる新たな構文が追加。 closure の先頭 引数宣言の前に [unowned self] のような構文追加により self を unowned としてキャプチャすることができる。