3を利用するように変換した時の自動変換結果については、こちらに記述しました。10にして、一部、赤いエラーが出たところなどを直すことになります。それらについてまとめておきます。署名ができない!実は、この問題に最後まで苦しみました。署名に関するプロジェクトの設定をあれこれいじってもエラーが出て完了しませんでした。エラーのログをよく見ると、こんなメッセージが見えました。1しかし、リソースフォークをいじった記憶もありません。overflowのサイトに答えがありました。画像なんかにはアプリケーションが勝手にリソースをつけていたりすることがあるので、それを消せばいいということでした。リソース等は署名対象外にしないといけないというのは、最近ルールとして増えたのかもしれません。-rc」、これでエラーがなくなりました。このコマンドは、リソースフォークやFinder情報などのファイルの付加情報を消します。-cで消す、-rでサブディレクトリをすべてさらいます。ファイルそのものは消しません。拡張情報の処理コマンドです。変換されない箇所が残るパターンNSURLをURLは自動的に変換してくれると思ったのですが、以下のようなパターンの場合は、自動変換してくれず、手動で書き換えました。NSを消すだけですが、AnyObjectはAnyにするなどを知っておかないと作業は面倒になります。完了時のクロージャーはもしかすると、キーワードなしで、閉じかっこの次に記述しておけば変換してくれたのかもしれませんが、これは想像です。以下のようなプログラムがあるとします。いずれも、返り値のあるメソッド呼び出しであり、インスタンス生成です。unused」などというメッセージで警告となります。返り値が使われていないというのです。以下のサンプルはさておき、返り値の不要な場合は時々あります。いちいち変数を定義すると、今度はその変数が使われていないと言った警告が出ます。(ちなみに、おなじみの定数「NSUTF8StringEncoding」は、「String.Encoding.utf8」のように、よりスッキリした記述に変わっています。続いてステートメントを記述します。空代入のようなことをするということです。これも、返り値があるのに忘れているようなミスを防ぐためということになっていますが、ちょっとやりすぎな気もしますね。8でのコンバートをする時に、定義定数がない状態でのコードが変更されます。したがって、#if等で変数が定義されているかどうかを確認するような場合、ELSE側だけが変換されました。変換されない方は手作業で変更するしかありません。9まではAppDelegateクラスのapplication(_:didFinishLaunchingWithOptions:)メソッドに、例えば以下のようなプログラムを書いていました。変数applicationはメソッドの第1引数です。nil)application.registerUserNotificationSettings(settings)記述方法が以下のように大きく変わります。NotificationフレームワークのUNが頭文字)クラスのインスタンスをcurrentメソッドで得て、requestAuthorizationメソッドで機能の利用を要求します。引数は定数(.badgeがホーム画面のアプリケーションのアイコンにつけるバッヂの許可で、他に.soundなどの定数がある)の配列を指定します。処理完了時に実行されるクロージャーが続きます。許可の可否に応じて処理をすることができますが、何も書かなくても動作はします。in}ちなみにrequestAuthorizationは2つの引数を持つので、次のような記述が可能です。こちらは定義通りです。Closure)ので、上記の書き方となります。in})なお、処理完了時のクロージャーに何も処理がない場合の一番短い書き方は、これではないかと思われます。in}openURLがdeprecatedになったUPApplicationクラスのopenURLメソッドがdeprecatedになり、openを使うようにと警告が出てきます。最初の引数にURLを指定するのは同じですが、optionsと完了時のクロージャーも記述します。それまで、openURLを使っていたのなら、おそらく当初は増えた引数は何も指定しないでOKでしょう。options:の後にnilを指定したらエラーになります。中身が空のDictionaryを指定するのが手軽だと思います。最後のクロージャーは閉じかっこの後に記述します。何も処理がない場合でも、引数並びは評価されるためnilは指定できません。いう記述でもいいでしょう。in}NSRangeとRangeの変換は相変わらずできないこれ不便ですよね。文字列処理だけしていればRangeだけしか出ないのかもしれませんが、UITextFieldDelegateのメソッドなんかは文字列の変更箇所がNSRangeでやってくるので、Stringに対しての処理をしたい場合は、それをRangeに変更したいわけです。NSStringで処理ということもありますが、せっかくSwiftなのだからStringで処理をしたいわけです。9の時には、自分で変換メソッドを作っていました。3にはないらしく、index関数を利用して改めて作り直しました。extensiondでStringクラスにメソッドを追加して変換しています。以前のメソッドよりもだいぶんシンプルに短く書いていますが、それは自分自身のSwiftの知識が増えたからかもしれません。いった明示的なキャストをする必要があります。8.0が正式に出ました。あるアプリケーションのプロジェクトをコンバートした時に自動的に書き換えられた結果をもとにどのような変更があったのかを記録しておきます。3でdeprecatedになるという警告の箇所は、警告が出ないように変更した結果です。それ以前のバージョンのSwiftで作られたソースでは、もっと様々な変更の必要があると思います。9.3のままの状態でコンパイルが通るようにしてみました。クラスそのものが変更されたもの以下のクラスについて、名前が変更されています。9.3)の場合の記述で、矢印の右側の記述に自動的に変換されたことを示しています。NSの付いたクラス名が付いていないものに変わってきています。おなじみのNSURLやNSErrorが、配列や文字列ど同様NSのないクラス名に変更されています。クラスの機能については大きくは変わっていないようです。NSURLSession及びその名前で始まるNSURLSessionTaskも含めて、頭の「NS」はなくなっていますが、今日現在、ドキュメンテーション中に「NSURLSession」が残っていたりします。最後のURLSession.AuthChallengeDispositionは列挙型です。NSUserDefaults→UserDefaultsNSError→ErrorNSURL→URLNSBundle→BundleNSURLSession→URLSessionNSURLCredential→URLCredentialNSURLAuthenticationChallenge→URLAuthenticationChallengeNSURLSessionAuthChallengeDisposition→URLSession.AuthChallengeDispositionAnyObject→Anyインスタンスを得るメソッドがシンプルなプロパティに「UIApplication.sharedApplication()」などは頻繁に記述していたのですが、Applicationという単語の重なりがなんか重い感じがしていましたが、「UIApplication.shared」のように、長いスタティックメソッドが短いプロパティに変更されました。コードがかなりスッキリします。Dispatch関連のAPIをクラスにラップしたものです。4から関数としてサポートしているものもあり、要するにやっとクラスとして使えるようにAPIを整えたという状況のようです。最後のUIColorクラスは、いくつかの色のオブジェクトを得るスタティックメソッドが用意されていましたが、これもColorの重複があったものの、redやgreen、blackといったプロパティで得られるようになりました。従来の3種類から、open、public、internal、fileprivate、privateの5段階に変更されました。3より導入されたものです。従来のprivateは、全部fileprivateに変更されてしまいます。省略時にinternalになるのは変更ありません。2.xではprivateによるアクセス制限はクラス単位ではなくファイル単位でした。したがって、1ファイルに2つのクラスを定義した場合、privateなプロパティでも別のクラスからアクセスができました。3ではファイル単位でのfileprivateと、クラス単位のprivateに分離しました。従来のprivateが現在のfileprivateになったということで、こうした変換を行なったのでしょう。publicとopenについては、元のpublicは現在はopenに対応します。3ではpublicはサブクラス化やoverrideできないという制約が付きます。3ではカンマで区切ったそれぞれの代入文にletが必要になりました。yのletは今までは不要だったのですが、これが入るようになります。print(a,b)}UIKitのAPIの変更メソッド名やプロパティ名などがあちらこちらで変わります。読みやすくはなります。UIViewControllerのshowViewController(_:sender:)、dismissViewControllerAnimated(_:completion:)、presentViewController(_:animated:completion:)の各メソッドが、show(_:sender:)、dismiss(animated:completion:)present(_:animated:completion:)へと極めて短くなりました。最初の引数にはキーワードをつけないということで統一されていて、最初のキーワードは関数名に組み込まれていましたが、状況によっては引数のキーワードとして使うようになりました。dismissのように通常のメソッドでも、最初の引数にキーワードが付くことがあります。UINavigationControllerクラスではpopViewControllerAnimated()がpopViewController(animated:)にはなるなど変化はあるものの、大きな変化のないクラスもあります。UIViewクラスのhidden、userInteractionEnabledプロパティはisHidden、isUserInteractionEnableとなりました。Boolean型のプロパティのインタフェースを「is+属性名」としたということで、この部分はJavaなどのルールに即したということでしょう。プロパティ名にあった「URL」はほぼ「url」で置き換えられており、URLで始まるプロパティもurlで始まるようになっています。定数についても、以前は.Badgeのように頭文字は大文字でしたが、.bridgeのようにドットの次は小文字になりました。Objective-Cで作ったクラスを入れていたのですが、そのクラスの定数も同様に頭文字が小文字になったので、この処理はブリッジ部分での変更であることが確かです。結果的に、クラス以外の頭文字は小文字というルールが浸透した感じです。メソッドだったものもプロパティとして扱えるものは、プロパティになりました。UIViewControllerクラスでは、supportedInterfaceOrientationsメソッドがあり、それをオーバーライドして返り値をプログラムで記述することで、自分で作っているビューコントローラでの挙動を変更できました。これが、supportedInterfaceOrientationsプロパティに変わります。値を返すように記述することで、プログラムがゲッターとして機能します。ように引数指定なしのクロージャのように記述するだけで変わりません。記述が必要になりました。3@escapingが追加されるクロージャーの引数定義WKWebViewのデリゲートメソッドの部分では、引数のクロージャーを持つものがありますが、メソッド定義の記述に@escapingが加わりました。9)ではこの@escapingはない状態で定義されていました。このアノテーションを追加することで、引数に設定されたクロージャーがメソッド実行後に消えてなくなってしないように保持をします。このクロージャー自体をlazyで指定したプロパティで使う場合や、あるいは配列にlazyプロパティを指定してさらにmapメソッドを適用することで、mapメソッドのクロージャーの適用を配列の要素を取得する時点で行うことができるのですが、そのmapメソッドの引数にクロージャーを指定するような場合に、@escapingで保持を指定するということになっています。8とはあまり関係ありませんが、配列に対するlazyプロパティについてはブログ等でほとんど見られないので、ちょっと試して見ました。サンプルプログラムを見てください。配列mに対して、mapメソッドを直接ではなく、lazy.map()で適用します。(Function))」と出てくるように、特殊なコレクションです。このnをsubscriptによりアクセスすると、そのアクセスした時にmapメソッドを実行して結果を返します。202という値が得られます。メソッドの適用をlazyにするという仕組みと言えるでしょう。2.3の段階で警告も含めてクリアしているので、++演算やそれを使ったfotなどの警告となっていた記述は一切ない状態だったので、それほど時間がかからずに変更はできました。して違いが出たところは概ね自動的に変更してくれるので、それはそれでいいのですが、仔細に見ることで色々と新しい機能も理解できるようになります。7.3がリリースされました。3でなくなる機能が、deprecatedとして出てくるようになりました。以前のように、いきなりコードに赤いエラーが出て動かなくなるより、はるかに気持ちの良い対応ですね。手元のいくつかのプロジェクトを早速開いてみました。x++やx–演算子の廃止です。こちらに詳細がありますが、まとめると初心者にとってわかりにくく、トリッキーなプログラムになりがちということで、廃止すべきという意見が通ったということです。x++と++xの違いとか、C言語のクイズとしては面白いかもしれませんが、読みやすいコードにするには、解釈しづらい言語仕様の排除というところでしょうか。変換しろということになっていますが、++の前後の位置を利用している場合や、x++の返り値を利用している場合には、単に置き換えで済まないかもしれません。__FUNCTION__が使えなくなり、#functionに置き換えるように出てきています。プロポーザルはこちらですが、アンダーラインを使うC言語由来の方法ではなく、#をコンパイラによる置き換えを記述できるようにするということでの変化ということになります。タイマー等で使っていたセレクタ型はSelector(“メソッド名:”)みたいに書いていましたが、#selector(クラス名.メソッド名(引数))のように記述するようになります。メソッド名を文字列で記述するとなると、間違ったメソッド名かどうかの判断ができないので、記述を見直すのは確かに必要です。こちらにプロポーザルがあります。オープンソースとなったSwiftですが、早速多数のプロポーザルが行われ、それが言語仕様となり、Xcodeに反映されるというダイナミズムがこのようにすでに動き始めています。Swiftは過去に例を見ない速度で進化し始めているといえるでしょう。積極的に使うSwiftの特徴として、クラス名のみで示す型では、nil値を許さないことです。?や!でnil値を許す変数の定義などができます。Optionalと呼ばれています。UILabel!ここで、アウトレットについて考えてみます。Builderで線を引くなどして参照先のオブジェクトが指定されていれば、ストーリーボードのロード時などに自動的に参照先が設定されます。Optionalのどちらかにしないといけません。Optionalになります。aLabel.text}のように、ifで囲う必要があります。なると、Objective-Cで作られたプログラムを移植するようなときに、流れが変わってしまい、作業効率が悪くなるということもあると思います。Optionalをアウトレットの推奨形態にしていると思われます。Optionalかは、仕組みの上ではどちらでも構わないのではないでしょうか。nil値を許せばいいのです。Bindingを記述することになるので、不都合はなく、むしろ好都合かもしれません。余分に記述するのが目障りということもあるかもしれませんが、予防的な措置であれば、むしろ歓迎すべきです。これらの点は、個人的な嗜好ではありますが、むしろ評価すべきです。そもそも、Swfitは安全な言語ということが謳い文句だったはずです。あれば、Optionalをもっと積極的に使うべきではないでしょうか。Optionalにしたら、面倒と思うかもしれません。以下はいずれも、エラーになります。tagというプロパティはないとエラーでは記述されています。myLabel2.tagしかしながら、若干の誤差を許していただければ、基本的には非常に緩いルールでこれらのエラーは逃れられます。それは、Optionalなプロパティが左辺にあるときには、単に、変数名に?をつけるだけでいいのです。右辺で利用するときには原則としてバインディングを行います。label.text}これだけのことでいいのです。アウトレットを含めたプロパティは、Optionalで定義する〜このルールでも構わないと考えます。