"JavaScriptからletを絶滅させ、constのみにするためのレシピ集" という投稿を読みました。半分はネタだと思いますが、 JavaScript で const を追求すると可読性が厳しそう だなと感じました。 一方で、他の言語だと同じことにチャレンジしても、もう少しマシに書けそうに思いました。僕が普段一番よく使っている言語は Swift です。そこで、試しに Swift で同じ内容のコードを書いてみて、 JavaScript で let を「絶滅」させるために足りないもの が何かを考えてみました。 なお、 JavaScript のコードは注釈がない限り上記の投稿からの引用です。 変数・定数宣言のためのキーワード 変数 定数

"JavaScriptからletを絶滅させ、constのみにするためのレシピ集" という投稿を読みました。半分はネタだと思いますが、 JavaScript で const を追求すると可読性が厳しそう だなと感じました。 一方で、他の言語だと同じことにチャレンジしても、もう少しマシに書けそうに思いました。僕が普段一番よく使っている言語は Swift です。そこで、試しに Swift で同じ内容のコードを書いてみて、 JavaScript で let を「絶滅」させるために足りないもの が何かを考えてみました。 なお、 JavaScript のコードは注釈がない限り上記の投稿からの引用です。 変数・定数宣言のためのキーワード 変数 定数

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

iOS アプリ開発において、 Fat View Controller はよく知られたアンチパターンです。 iOS アプリ開発では View Controller が大元にあるので、 View Controller になんでもかんでも実装していると、どんどん View Controller が肥大化してしまいます。 Fat View Controller には、たとえば次のような問題があります。 UI とロジックが分離されておらずテストしづらい。 コードの見通しが悪く、可読性が悪い。 状態管理が複雑になり、修正時の影響範囲を見通しづらい。 みんなで同じファイルを触ることになり、コンフリクトが起こりやすい。 そんな Fat View Controller との戦い方の知見を共有し合うために、たくさんのiOSエンジニアで同じ Fat View Controller のリファクタリングに取り組んで

本日（2020年3月25日、現地時間では24日） Swift 5.2 がリリースされました。 Swift 5.2 がフォーカスしているのは、コード補完やエラーメッセージの改善など、開発者の UX 改善で、言語仕様に加えられた変更は多くありません。 UX の改善点については公式ブログが詳しく解説しているので、本投稿では Swift 5.2 における言語仕様の変更点について紹介します。 Swift 5.2 で言語について加えられた変更は次の二つです。 SE-0249: Key Path Expressions as Functions SE-0253: Callable values of user-defined nominal types SE-0249: Key Path Expressions as Functions Key Path 式を関数として渡せるようにする変更です。 たとえ

プログラミング × すごろく 数年前、娘とすごろくで遊んでいて、「すごろくってソースコードに似てるな」と思いました。すごろくのマスには色々な指示が書かれていて、ちょっと複雑なものだと「サイコロを振って 6 が出たら矢印の先のマスに進む。」のような感じです。これはまさに条件分岐です。 すごろくなら幼稚園児でも理解できます。プログラムのコードをすごろくで表現すれば、プログラミング初心者がプログラムの動作を理解する助けになるかもしれないと思いました（ただし、普通のすごろくでは止まったマスに書かれた指示だけを実行しますが、プログラムは通過したすべての行を実行しないといけないので、プログラムをすごろくで表現すると、止まったマスだけでなく通過したマスに書かれた指示もすべて実行するルールですごろくを遊ぶ必要があります）。 たとえば、次のようにすごろくのマスの中にコードと日本語の両方で指示を書けば、コード

Swift の機能提案は Swift Evolution で行われるのですが、 Swift の標準ライブラリに Result 型を追加するプロポーザル SE-0235 が承認されました。その結果、 Swift 5 で Result が標準ライブラリに追加されます。 本投稿では Result とは何か いつ Result を使うべきか Result をどのように扱うべきか 今のうちに Result に備える方法 を説明します。 Result とは何か Swift にはサードパーティ製の antitypical/Result という人気ライブラリがあり、 Result に馴染みのある人も多いと思います。本節では、 Result に馴染みのない人のために Result について簡単に説明します。 Result はエラーハンドリングに用いられる型で、次のように宣言されます。 public enum

Swift 4.1 のおける最も大きな変更の一つは Conditional Conformance 1のサポートです。 Conditional Conformance はジェネリクス関連の言語仕様の一つです。 本投稿では、 Conditional Conformance とは何か、何がうれしいのか、どのようなことができるようになったのかということを説明します。 Conditional Conformance とは Swift 4.0 まででも、次のようなコードは正しく実行できました。

あけましておめでとうございます。新年早々おもしろツイートがバズっていました。 おっ、null安全だ pic.twitter.com/RFta3RFXxu — yuga panda (@yugapanda) 2018年1月1日 これは、ネタとしてはおもしろいんですが、 Optional について良く知らないと 「 null 安全とか言っても『Optional(2018)年』 みたいな新しい問題を生んでしまうんだな。」 とミスリーディングされてしまう可能性があります。なので、 『Optional(2018)年』と表示されること自体は問題ではなく、むしろ null 安全（ null safety ）のために必要である 『Optional(2018)年』は確実に防ぐことができ、心配する必要はない ということをマジレスしてみます。 そもそも何が問題なのか 今回『Optional(2018)年』と表示

追記 (2020-08-05) 投稿時には async/await が Swift 5 で導入されそうでしたが、 2020 年 8 月（ Swift 5.2 ）現在ではまだ async/await は導入されておらず、 Swift 6 での導入が有力になっています。 async/await は "Swift Concurrency Manifesto" の最初の Part に挙げられていますが、公式にアナウンスされた "On the road to Swift 6" の中で Concurrency が挙げられています。 先日、 async に関する PR が Swift リポジトリの master ブランチにマージされました。 2ヶ月ほど前、 Chris Lattner から swift-evolution に "async/await + actors" というタイトルで驚きのメールが流

これは Mobile Act OSAKA #1 での発表した内容をまとめたものです。 iOS / Android 双方に関係あることとして、 Kotlin の List と Swift の Array を比べてみます。 一番大事なこと 最初に一番大事なことを言います。それは、 Kotlin の List は 参照型 だということです。コレクションが参照型なのは当たり前と思うかもしれませんが、 Swift の Array はなんと 値型 です。この違いがこれから説明するすべての違いを生む原因なので重要です。 ミュータビリティ では実際にどんな違いがあるのか、まずはミュータビリティについてです。

先日 Swift 4 がリリースされました。みんな注目しているのは Codable など劇的にコーディングが楽になる新機能だと思いますが、ちょっとした便利な小技もあります。 そんな、 Swift 4 の小技の魅力の一面を 3 行にぎゅっと詰め込んだコードを思い付いたので紹介します。 // User の Array から、 team ごとの人数を集計する let teamToCount: [String: Int] = users.reduce(into: [:]) { teamToCount, user in teamToCount[user.team, default: 0] += 1 } これは、 User の Array を team ごとに集計するコードで、次の二つの新 API を使っています。 Dictionary の subscript(_:default:) （リファレンス）

これらは、表中の「リプレース対象言語」に挙げたように、多くのメジャー言語に対する代替手段でもあります。 Java の代わりには Kotlin や Ceylon が、 JavaScript には TypeScript や Flow が、 Objective-C には Swift が、そして PHP には Hack があります。 Python は自身に null 安全 を取り込みました。 Crystal は直接 Ruby と連携して使えるわけではありませんが、 Ruby 風の null 安全 な言語です。 Rust は C++ の代替を目指して開発され、 Firefox の一部で C++ のコードを置き換えるのに使われています [^100] 。 null が引き起こしてきた数々の問題を考えると、僕は、 null 安全 は GC （やその他の安全なメモリ管理手法）に匹敵するプログラミング言語の進

Kotlin が Android の公式言語になることが Goole I/O 2017 で発表されました。 Java プログラマが Kotlin を始めることがこれから多くなると思うので、 Kotlin をスムーズに始められるように次の 3 点についてまとめます。 Javaとほぼ同じところ 新しい考え方が必要でつまづきがちなところ Kotlinならではの便利なこと すべてを一つの投稿にすると長くなるので連載形式とし、本投稿では最初の「Javaと同じところ」について説明します。 Kotlinって何？ 本題の前に、 Kotlin について簡単に説明します。 まずは↓の Android のコードを見て下さい。これは Android Studio が生成するテンプレートの Kotlin 版です。 Android アプリ開発者であれば、初見でも概ね何をしているのかわかると思います。 class Ma

Kotlin が Android の公式言語になることが Goole I/O 2017 で発表されました。これから Kotlin を始める Java プログラマが多くなると思うので、本投稿では Java プログラマが Kotlin でつまづきがちなところについて説明します。 本投稿は単独で理解できるように書いていますが、↓の連載の第二弾です。 Kotlin の基礎的な構文は理解していることを前提としているので、 Kotlin の基礎については　"Javaとほぼ同じところ" を御覧下さい。 Javaとほぼ同じところ 新しい考え方が必要でつまづきがちなところ ←この投稿で扱う内容 Kotlinならではの便利なこと 新しい考え方が必要でつまづきがちなところ 新しい概念を学ぶときには、何ができるのかだけでなく、どうしてそうなっているのかがわからないとそれをうまく使いこなすことができません。 本節で

僕は、 Java の検査例外のコンセプトは素晴らしいと考えていますが、世間ではあまり好かれていないようです。 C# や Scala, Kotlin などの後続言語では採用されず、僕の知る限り Java 以降、検査例外（的なもの）を採用したメジャー言語は Swift だけです。 ただし、Swift の検査例外（的なもの）はいくつかの点で Java の検査例外と異なっています。 Swift は後続だけあって何かしらの改善を試みているわけです。その取り組みがおもしろいので、 Swift の検査例外的なものが Java の検査例外と何が違い、それがどのような意味を持つのかを紹介します。 throws 節でエラーの型を指定できない Java では

あまり知られてませんが、エラー処理について、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年かけて逆に素晴らしいと思えてきたので、今日はそれについて発表します。本質

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

これは 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 で発表した際にも参考文献にしまし

// Java List<String> strings = new ArrayList<String>(); ArrayList インスタンスを ArrayList 型の変数として取り回すことはめずらしく、スーパータイプである List 型として扱います。これによって、 ArrayList なのか LinkedList なのかという実装の違いを気にすることなく一般的な List としてコードを書くことができ、再利用性が高まります。 Swift では Array も Set もみんな Sequence プロトコルを満たしており、同じように Array や Set を一般的な Sequence 型として扱いたいことがあります。 Swift のプロトコルはジェネリクスの代わりに associatedtype を使うので、構文上 Sequence<String> のようには書けません。しかし、型