ライブラリとアプリというより、ある関数の機能の関心が、その動作に含まれるローレベルの動作に含まれるかどうか、ってことだと思うんですよね

11:26 PM

例えば func callAPI(request:) async throws -> Response みたいな場合、

11:26 PM

関心の粒度はAPIの仕様の粒度であって、

11:26 PM

それがどういうネットワークライブラリ(URLSession? async-http-client?) なのか、はたまたネットワークじゃなくてスタブに繋がっているのか

11:27 PM

みたいなその実現方法までは関心をもたない、抽象化してしまったほうが

11:27 PM

便利でもある、みたいな。

11:27 PM

エラー型を正確に列挙しようとすると、必然的にその実現方法に強く依存したインタフェースになってしまうので

11:27 PM

関心を上層に限定して抽象化することができなくなる。 (edited)

11:29 PM

Contains common infrastructural code for both SwiftPM and llbuild. - apple/swift-tools-support-core

11:30 PM

他にもこういう topologicalSort みたいな純粋なロジックの関数とかは、下層の実現方法の選択肢という概念がそもそもあてはまらなくて、ありえる失敗が固定されてるから、エラー型を列挙するのと相性が良い (edited)