Swift は iOS アプリを作るための言語というイメージが強いと思います。しかし、実際にはサーバーサイドプログラムや機械学習、コマンドラインツールの開発など、 多様な目的で利用できる汎用言語です 。 2015 年にオープンソース化され、 Linux でも動作し、近々 Windows もサポートされる予定です。 Swift は Apple の言語ですが、それは TypeScript が Microsoft の、 Go が Google の言語だというのと同じ程度の意味しか持たないと思います。 Swift Core Team には Google のエンジニアも入っていますし、新しい言語の機能はすべて、オープンな場で議論された上で決定されます。 そんな Swift にとって期待される二つの分野が、 Web のクライアントサイドとサーバーサイドです。 WebAssembly に対応することで、

これは Swift Tweets の発表をまとめたものです（次回開催はこちら）。イベントのスポンサーとして Qiita に許可をいただいた上で投稿しています。 ありがとうございました！Q&Aは他の人の発表中でも構わないのでリプを飛ばして下さい。 続いては僕 @koher の発表で、タイトルは "Swiftのエラー4分類が素晴らしすぎるのでみんなに知ってほしい" です。 #swtws — koher (@koher) 2017年1月14日 第 1 部: Swift の 4 種類のエラーについて あまり知られてませんが、エラー処理について、 Swift 2.0 設計時に Core Team がまとめた "Error Handling Rationale and Proposal" というドキュメントがあります。このドキュメントは、僕が去年 try! Swift で発表した際にも参考文献にしまし

この新しい reduce は、これまでの reduce の抱えていた問題を鮮やかに解決してくれるものなので、その素晴らしさについて説明します。 これまでのreduceの問題点 reduce を使って Array を生成する場合を考えてみます。たとえば、 [2, 3, 5] という Array があったときに [2, 2+3, 2+3+5] のように、その要素とそれまでの要素の合計値を格納した Array を作りたいとします[^1]。 そのような処理は reduce を使って↓のように書けます。

最近にわかに 型クラス が盛り上がっているようです。しかし、型クラスはインタフェースに似たものだという意見もあればまったく別のものだという意見もあり、混乱する人が多いのではないかと思います。 そのような混乱を招く理由は、 インタフェースと型クラスはどちらも抽象化を実現するためのもの であり、 インタフェースでも型クラスでもできること インタフェースでしかできないこと 型クラスでしかできないこと があるからです。 1 に着目した人は似ていると語り、 2 や 3 に着目した人はまったく違うものだと言います。 本投稿では、 Java / Kotlin のインタフェース、 Haskell の型クラス、 Swift のプロトコルを比較し、上記の 3 点を整理します。 Swift のプロトコルを加えるのは、 Swift のプロトコルがインタフェースと型クラスの両方の性質を備えたものなので、比較対象とし

Error Handling Rationale and Proposal がリンク切れになっていたので、こちらがリダイレクト先として妥当でしょうか

あまり知られてませんが、エラー処理について、Swift 2.0設計時にCore Teamがまとめた"Error Handling Rationale and Proposal"というドキュメントがあります。 https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst このドキュメントは、僕が去年try! Swiftで発表した際にも参考文献にしました。 https://github.com/koher/try-swift-2016/blob/master/slides.md 長いし（僕にとっては）英語が難しいし、具体例も少ないしで読むのがとても大変でした。 その中でエラーの分類について記述があるんですが、当時ピンと来なかったのが1年かけて逆に素晴らしいと思えてきたので、今日はそれについて発表します。本質

Swift その2 の最後の 3 日が投稿されなかったので代わりに 3 連投です。 @mono0926 さんが同様の目的で Qiita 外の 7 選をやっていたので、僕は Qiita の投稿でやりたいと思います。 とはいえ、ストック数で選んだのではおもしろくありません。実は今、僕は Qiita の投稿を 独自のアルゴリズムでランク付け するサービスを作っており、年明けの 1 月 4 日のリリースを予定しております。現在最終調整中なのですが、そのアルゴリズムが選んだ 2015 年の投稿 TOP 100 から、 Swift タグのついたものを抜粋して紹介します。 1. Android開発を受注したからKotlinをガッツリ使ってみたら最高だった (487.9 pt) Swift タグのついた投稿で 1 位に選ばれたのは、僕の同僚（後輩）である @omochimetaru の投稿でした。 直接

去る 12 月 3 日、ついに Swift がオープンソースになりました！！ 僕は、今度 try! Swift で Swift について話す予定なんですが、 Swift がオープンソースになったからには、コンパイラの中身まで見て証拠を掴んだ上で話さなければならないこともあります。 そんなわけで早速コンパイラのソースを読もうと思ったんですが、目的なく漫然と読むのも辛いです。そこで、勉強がてら Swift のコンパイラを改造して前からほしいと思っていた構文を追加してみました（ リポジトリはこちら ）。 改造の内容は次の二つです。 標準ライブラリに Either<L, R> という型を追加 Either<L, R> のシンタックスシュガー L|R を追加 これによって、次のようなコードが書けるようになりました。 // Int|String は Either<Int, String> のシンタック

Swift 2.0 / Xcode 7 で Carthage を使って Alamofire や SwiftyJSON を管理する方法iOSSwiftCarthage Swift 2.0 / Xcode 7 では Swift の構文が大きく変更されており、 Alamofire や SwiftyJSON をはじめ、多くの Swift ライブラリでは Swift 2.0 / Xcode 7 用のブランチが作られて開発されています。 Alamofire: swift-2.0 SwiftyJSON: xcode7 SWXMLHash xcode-7.0 PromiseK: swift-2.0 ← これは有名ライブラリではなく僕の自作ライブラリです。 しかし、 Carthage を使ってこれらを管理しようとしても、 README に書いてあるような Cartfile の記述方法ではうまくいきません。上

(2015.09.08 追記) Swift 2.0 ではこんなことをしなくても Either を作ることができるようになっています。 Either について詳しくはこちら。 (2014.12.13 追記) ここに書いた方法は遅延評価の影響でクロージャにキャプチャされた変数が変更された時などに問題がありました。思い付きで書くと良くないですね。イミュータブルな世界なら問題ないのですが。 僕の思い付くミュータブルな世界でも使えるワークアラウンドは↓みたいな感じです。 enum Either<T, U> { case Left(Container<T>) case Right(Container<U>) static func left(left:T) -> Either<T, U> { return .Left(Container<T>(left)) } static func right(ri

本投稿の個別の説明（ Optional とは何か、 ?. と map, flatMap の関係、その背後にあるモナドという概念）は 2017 年現在でも通用するものですが、 Swift の Optional の使い方としては、僕の考えとのズレが大きくなってきました。 Swift の Optional をいつ・どのように使うべきかについてもまとめた ので、そちらも併せて御覧下さい。 Optional は Swift の仕様の中でもっとも素晴らしいものの一つだと、僕は考えています。 null参照 （多くの言語で nil や null と呼ばれるもの）を発明したトニー・ホーアは次のように述べています[^1]。 それは10億ドルにも相当する私の誤りだ。null参照を発明したのは1965年のことだった。（中略）これは後に数え切れない過ち、脆弱性、システムクラッシュを引き起こし、過去40年間で10億ド

Swift を書いていると Optional を多用しますが、次のように Optional に包まれた値同士を計算したいときに面倒です。

はじめに この3週間ほど仕事でSwiftを使ってアプリ開発をしてみました。その感想として、すべての人に当てはまるとは言えませんが、 多くのiOSアプリ開発者にとっては今すぐにSwiftを使い始める価値があると感じました（Swift 1.0がリリースされてから1ヶ月ほど経った2014年10月時点での感想です）。 そこで、この投稿では Swiftの利点とよくある不安や疑問に対する回答 を書いていきます。 対象となる読者 この投稿は次のようなiOSアプリ開発者を対象としています。 Objective-Cで十分でしょと思っている人 なんとなくSwift良さそうだけど踏み出せない人 Swiftがいいのはわかったけどまだ実案件では使えないと思う人 どうしてObjective-CよりSwiftを使った方がいいの？ Optional Type（これだけでSwiftを使う価値あり） 私見ですが、Object

Swiftも1.0がリリースされ、SwiftでiOSアプリを申請できるようになりました。Swiftはとても学びやすい言語ですが、 Array （や Dictionary ）の挙動については最初戸惑う人が多いのではないかと思います。そこで、Swiftを学習するときに Array についてハマりそうな点をまとめました。 多くの言語では配列やリストは 参照型（Reference Type） として扱われますが、 Swiftの Array は 値型（Value Type） です。配列やリストが参照型である言語（Objective-C、C#、Java、JavaScript、Python、Ruby、…）に慣れ親しんでいる人ほど、この違いに戸惑うのではないかと思います。 本稿では Arrayが値型であることによってハマりがちなポイントについてまとめます 。個別のメソッドの使い方などでハマりがちな点につい

(2014.9.3に追記) 本投稿に書かれているのはbeta 2までの古いSwiftについての情報ですのでご注意下さい 。beta 3以降では、Arrayはletのときに要素が変更できなくなり、すばらしく生まれかわりました。 SwiftのArrayとDictionaryはそれぞれ可変長配列と連想配列を表す基本的なコレクション型です。それらのインスタンスを定数に格納した場合について、その仕様に大きな違いがあります[*1]。それは、↓のように、定数のArrayインスタンスの要素は変更が可能ですが、Dictionaryインスタンスでは変更することができないというものです。 let array = [1, 2, 3] // Arrayインスタンスを定数arrayに格納 array[0] = 999 // これはOK let dictionary = [ "abc": 123, "def": 456

(2015.11.18に追記) 「Swift List」 で検索するとこの投稿にたどり着いてしまいますが、関数型言語でいうところのリストをお求めの方は "Swiftでhead、tailにパターンマッチできる遅延リスト" を御覧下さい。 (2014.7.24に追記) SwiftのArrayの新仕様（beta 3以降）がヤバイどころかすばらしいのでまとめました 。 (2014.7.10に追記) SwiftのArrayがヤバくなくなりました。 本投稿に書かれているのはbeta 2までの古いSwiftについての情報ですのでご注意下さい 。beta 3以降では次のような挙動となり、値型としてごく自然な挙動になりました。 var a = [11, 22, 33] var b = a a[0] = 777 // b[0]は777にならない a.append(44) a[0] = 888 // b[0]は