はてなブックマーク

Swift 5.5 で Swift に Concurrency （並行処理）関連の言語機能が追加されました。これによって、 Swift で非同期処理・並行処理のコードをより簡潔かつ安全に書くことができるようになります。 しかし、 Swift Concurrency は Structured Concurrency や Actor など、多くの人にとって馴染みが薄いだろうと思われる概念を含みます。具体例を通して効率よく Swift Concurrency を習得できるように、本記事では iOS アプリを題材に、 Swift Concurrency 導入以前（ Before ）と導入後（ After ）のコードを比較することで、何がどのように変わるのかを紹介します。 なお、 Swift Concurrency 関連の機能は次の三つに大別できるため、本記事の Before & After の例も

Swift 未経験者が Swift で競技プログラミングに挑戦してみるための、 Swift の基本構文や標準ライブラリのチートシートです。競技プログラミングで必要そうなものに絞って掲載しています。より詳しい情報は公式ドキュメント "The Swift Programming Language" を御覧下さい。 本チートシートの各項目に素早くアクセスするには、ページ右下の "Contents" をご活用下さい。 Hello World

最近、 Swift リポジトリに並行処理関係の Pull Request (PR) が続々とマージされています。 たとえば、次のような PR があります。 Add async to the Swift type system. #33147 Add @asyncHandler attribute. #33476 Import "did" delegate methods as @asyncHandler. #34065 Import Objective-C methods with completion handlers as async #33674 Basic support for actor classes and actor isolation #33906 Swift の並行処理（ Concurrency ）関連の機能については、 2020 年 1 月に発表された "On th

Swift ではこれまで @escaping な引数にクロージャ式を渡す場合、クロージャ式の中から self のメンバにアクセスしようとすると、明示的に self. を書く必要がありました。しかし、 Swift 5.3 では SwiftUI のコードを書く多くのケースで self. を省略できるようになります。 SE-0269: Increase availability of implicit self in @escaping closures when reference cycles are unlikely to occur そもそも何のために self. を書かないといけなかったのか そもそも self. が強制されていた理由は何でしょうか。それは 循環参照によるメモリリーク を避けるためです。 たとえば、次の Clock クラスは、 Clock と Timer が互いに参照し