Swiftは開発者を強制的に新しい世界に連れて行く

Swift 2.2で書かれた大量のコードをSwift 3.0に書き換えました。書いている最中は夢中になってやっていたので、疲れが一気に押し寄せてきました。一段落して改めて思った事があります。

下位互換?何それ?みたいな姿勢

ディスっているわけではないです。でも、Swiftの進化の仕方って、見出しみたいに感じませんか?Swift 1.0やSwift 1.1からSwift 2.0に書き換えたときも、大量の変更が発生しました。中には、同じ関数名なのに機能が変わっているものもあったりしました。
これって、日本のソフト業界の一般的な開発方法からみると、びっくりしますよね。ソフトの開発って、機能面や仕様面では下位互換を持たせるかどうかは、マーケティング的な要素も絡めて決まります。多くの場合は、ユーザーから怒られるのも嫌だし、下位互換は持たせるのが当たり前ってなると思います。ユーザーから見ても、直前まで出来たことが、バージョンアップしたら出来なくなって、戻すことも出来ないとかになったら悲惨です。そのソフトを使わなくなる理由にもなり得ます。これがソフトの肥大化の理由の一つです。
しかし、Swiftには、この考え方は通用しない。延命は出来ても、どこかのタイミングで、パラダイムシフトを伴うコード変更を余儀なくされる。Swift 2.0になったとき、これで安定すると思っていたら、Swift 3.0はもっと大きな変更が大量に発生しました。

どのように新しい世界に連れて行くか?

既存のユーザー(開発者)をどのように新しい世界に連れて行くか?その考え方の違いがあると思います。
C言語やC++の場合、古い構文で書かれたコードも基本的には、そのまま、コンパイルして、実行することが出来ます。OSの制約により、動かなくなることはありますが、これは、言語レベルや標準ライブラリレベルの話ではないです。
ソースレベルでの下位互換を持つ形で、新しい世界に行きたいユーザーだけが、自ら新しい世界へ入っていく。特に新しい世界に興味が無ければ、留まっていられるというスタイルです。
Swiftは、新しい構文が導入され、古い構文で書かれたコードはコンパイルも出来なくなります。そのため、Swiftを使い続けるのであれば、新しい世界に行かなければいけません。もちろん、コンパイラや開発環境を古いままにしておいて、留まるという選択肢や、コンパイラオプションで古いコードが使えるようにするという方法もあります。しかし、いつかは動作環境や新しい技術が必要になります。
新しい世界に行くときに、ソースレベルでの互換性は無いが、新しい構文に変換するための道具は提供する。だから、みんな、新しい世界へ入っていこうよと、引っ張っていくというスタイルです。

どっちがよいのだろうか?

どっちがよいのだろうか?一言ではバッサリ決められる話では無いです。古いものを切り捨てることで、大きな変革と進化を起こせます。しかし、変化が大きいほど、影響が大きいほど反発もあります。
個人的にも葛藤があります。
だけど、Swift 3.0のコードは確かに分かりやすい。考え方が伝わりやすい。
たとえば、同じ機能を持った関数で、引数が異なるというときに、Swift 2.xまでは、Objective-Cのように、長い関数名になっていました。それも、第1引数に合わせて、少しずつ名前が違うというものでした。
Swift 3.0では、短いシンプルな名前で、機能が同じものは、同じ名前になっている。引数が異なるだけ。これは、C++のオーバーロードの考え方にも似ていると思います。これが、とても分かりやすい。
「Swift API Design Guidelines」という形で考え方がまとめられ、一気に、これに従うように標準ライブラリが変更され、それが、全体的なわかりやすさの理由になっています。そして、この変更が、Swift 3.0での大量のコード修正につながっています。

Swift API Design Guidelinesについてはこちら。これからSwiftでコードを書くときは、このガイドラインに従って書くのが良いと思います。私もライブラリをこれに合わせて書き直す予定です。

関連記事

  1. [解決] MySQLを古いバージョンに戻せない

  2. Mac用Subversionクライアントから3つピックアップ

  3. クラスのモダン化

  4. iPhoneやiPadでのフォルダはジャンルより作業で区切った方が良さ…

  5. VMware FusionでSierraを動かすときはメモリ設定に注意…

  6. Objective-Cのクラスの前方宣言がないと困ること

最近の著書

最近の記事