I/O の明示

fn read_file(path: &str) -> std::io::Result<String>

fn read_file(path: &str) -> std::io::Result<String> {
    std::fs::read_to_string(path)
}

fn double(x: i32) -> i32 {
    let _ = read_file("x"); // 呼べてしまう。コンパイラは止めない
    x * 2
}

`io::Result`はI/Oが失敗しうることを示す命名規約であり、コンパイラソースコードを解析し、実行可能な形式（機械語や中間表現）に変換するプログラム。静的型付け言語では、実行前にコンパイラが型の不整合などをチェックする役割も担う。が強制するeffect注釈ではない。同期的なI/O呼び出しは通常の関数呼び出しと構文上区別されない。`async fn`は呼び出し元にも`async`か`.await`を要求し伝播する点で`io`に近いが、表しているのは「非同期に実行されうるか」であって、I/Oの有無そのものではない。`unsafe`が示すのはメモリ安全性のeffectで、I/Oとは別軸。

async fn find_user(id : UserId) -> User

async fn find_user(id : UserId) -> User { ... }

fn get_user(id : UserId) -> User {
  find_user(id) // 呼び出しにawait等の印は不要。コンパイラが型から同期/非同期を判定する
}

MoonBitのコルーチン方式はKotlinに近いが、非同期呼び出しに`await`のような印を書く必要がなく、コンパイラソースコードを解析し、実行可能な形式（機械語や中間表現）に変換するプログラム。静的型付け言語では、実行前にコンパイラが型の不整合などをチェックする役割も担う。が型から自動的に判定する。同期的なI/O（標準出力など）は`async`を伴わずに書けるため、シグネチャからI/O全体の有無を判別できる設計ではない。

func findUser(id: UserId) async throws -> User

func findUser(id: UserId) async throws -> User { /* ... */ }

func getUser(id: UserId) -> User {
    try await findUser(id: id) // NG: 自分もasync throwsが必要
}

func getUser(id: UserId) async throws -> User {
    try await findUser(id: id) // OK
}

`async`/`throws`はSwiftの関数型の一部として組み込まれており、呼び出し側は`await`/`try`を書く必要がある。ただし表しているのは非同期性とエラー送出であって、同期的なI/O（`FileManager`の一部API）はこれらを伴わずに呼べる。

suspend fun findUser(id: UserId): User

suspend fun findUser(id: UserId): User { /* ... */ }

fun getUser(id: UserId): User {
    findUser(id) // NG: suspend関数はsuspend文脈でしか呼べない
}

suspend fun getUser(id: UserId): User {
    findUser(id) // OK
}

`suspend`はコルーチンの中断可能性を示すマーカーで、I/O専用ではないが、多くのI/O処理がsuspend関数として書かれる。呼び出し元への伝播が強制される点は`io`ときわめて近いが、表現しているのは「中断されうるか」であって「I/Oを行うか」ではなく、同期的なI/O（`File.readText()`など）はsuspendなしで呼べてしまう。

String readFile(String path) throws IOException

String readFile(String path) throws IOException {
    return Files.readString(Path.of(path));
}

int square(int x) throws IOException {
    readFile("x"); // 呼ぶなら自分もthrowsを宣言する必要がある
    return x * x;
}

`IOException`はchecked exceptionのため、呼び出し元はcatchするか自身の`throws`に伝播させる必要があり、`io`の伝播規則に近い構造を持つ。ただし目的は例外処理でありeffectの分類ではなく、unchecked例外を投げるI/O API（一部のNIOなど）は対象外になる。

def findUser(id: UserId): IO[User]

def findUser(id: UserId): IO[User] = IO { /* ... */ }

def getUser(id: UserId): User =
  findUser(id).unsafeRunSync() // 言語としては呼べてしまう

def getUser(id: UserId): IO[User] =
  findUser(id) // 呼び出し側もIOのまま扱う、というのが規約

cats-effectやZIOの`IO`/`ZIO`型は、Haskellの`IO`と同じ考え方で副作用を値として表現し合成する。ただしScala言語自体はこれを強制しておらず、`println`のような素のメソッドをどの関数からでも直接呼べる。effectの分離はライブラリとチームの規約に依存する。

async Task<User> FindUserAsync(UserId id)

async Task<User> FindUserAsync(UserId id) { /* ... */ }

User GetUser(UserId id) {
    FindUserAsync(id); // 待たずに呼べてしまう。呼び出し元がasyncでなくてもコンパイルは通る
    ...
}

`Task`を返すメソッドを`async`を付けずに呼ぶこと自体は許される（結果を待たないだけ）。メソッド名に`Async`を付ける命名規約はあるが、コンパイラソースコードを解析し、実行可能な形式（機械語や中間表現）に変換するプログラム。静的型付け言語では、実行前にコンパイラが型の不整合などをチェックする役割も担う。は検査しない。同期的なファイルI/Oなどは、通常のメソッドと区別なく呼べる。

std::string readFile(const std::string& path);

std::string readFile(const std::string& path) {
    std::ifstream file(path);
    return std::string((std::istreambuf_iterator<char>(file)), {});
}

int square(int x) {
    readFile("x"); // 呼べてしまう
    return x * x;
}

`noexcept`は例外を投げないことを示すが、I/Oを行うかどうかとは無関係。標準ライブラリのI/O関数とそれ以外の関数は、シグネチャ上まったく区別されない。

char *read_file(const char *path);

char *read_file(const char *path) {
    FILE *f = fopen(path, "r");
    /* ... */
    return buf;
}

int square(int x) {
    read_file("x"); // 呼べてしまう。戻り値を無視してもコンパイルは通る
    return x * x;
}

`errno`はI/Oを含む多くのライブラリ関数が失敗を示すのに使うグローバル変数だが、設定されるかどうかは関数ごとの規約に過ぎず、型シグネチャには一切現れない。I/Oを行う関数と行わない関数は構文上まったく区別されず、C++・Goはこの「区別なし」をそのまま受け継いでいる。後発言語のasync/awaitやeffectシステムは、この「どの関数が何をするか分からない」という問題への解決策の系譜と見なせる。

func ReadFile(path string) (string, error)

func ReadFile(path string) (string, error) {
    b, err := os.ReadFile(path)
    return string(b), err
}

func Double(x int) int {
    ReadFile("x") // 戻り値を無視して呼べる
    return x * 2
}

`(T, error)`という戻り値の形はGoの慣用句だが、これは失敗しうることを示す規約であり、I/Oかどうかは示さない。goroutineの起動やチャネル操作も、通常の関数呼び出しと同じ構文で書ける。

fn findUser(allocator: std.mem.Allocator, id: UserId) !User

fn findUser(allocator: std.mem.Allocator, id: UserId) !User {
    return db.get(allocator, id);
}

fn square(allocator: std.mem.Allocator, x: i32) i32 {
    _ = findUser(allocator, .{}) catch {}; // 呼べてしまう。コンパイラは止めない
    return x * x;
}

ある関数がI/Oを行うかどうかを型シグネチャで区別する仕組みはなく、純粋な処理からI/Oを呼び出すことも制限されない。一方でZigは「no hidden control flow」「no hidden memory allocation」を設計思想として掲げており、allocationが必要な標準ライブラリ関数はallocatorを、出力を行う関数はwriterを、それぞれ明示的な引数として受け取るのが標準的な作法になっている。これはHaskellの`IO`モナド値を文脈（コンテナ）に包んだまま、その文脈を保って値を合成するための抽象化。Haskellでは`IO`型がI/Oという文脈を表すモナドで、`do`記法によってIOアクションを順に合成する。のような型レベルのeffect追跡ではなく「何に依存して動くか」を関数シグネチャに明示する規約であり、I/Oかどうかそのものを区別するわけではない。失敗し得る処理はerror union（`!T`）で表現されるが、それがI/Oによるものかは区別されない。

let read_file : string -> string

let read_file path = In_channel.read_all path

let square x =
  ignore (read_file "x"); (* 呼べてしまう *)
  x * x

OCaml 5で導入されたeffect handler（`effect`構文）は、軽量スレッドや協調的並行処理を実装するための機構で、Haskellのeffect systemのような型レベルの追跡は持たない。ある関数がどのeffectを起こしうるかは、現状の型シグネチャからは読み取れない。型システムへのeffect tracking追加は研究段階にある。

let readFile (path : string) : string

let readFile (path : string) : string =
    System.IO.File.ReadAllText(path)

let square x =
    readFile "x" |> ignore // 呼べてしまう。コンパイラは止めない
    x * x

OCamlと同じく、I/Oを行う関数と行わない関数は戻り値の型からは区別されない。非同期処理には`async { }`というcomputation expressionが用意されているが、これは`Async<'T>`という値を組み立てる糖衣構文であり、Haskellの`IO`のように型システムがI/O全体を強制的に分離する仕組みではない。同期的なファイルI/Oなどは、通常の関数呼び出しと同じ構文で書ける。

findUser :: UserId -> IO User

findUser :: UserId -> IO User
findUser id = ...

getUser :: UserId -> User
getUser id = findUser id -- 型エラー: IO User と User は別の型

getUser :: UserId -> IO User
getUser id = findUser id -- OK

I/Oを行う関数の戻り値は必ず`IO a`型になり、`IO a`から`a`を一般的な方法で取り出すことはできない（`do`記法でIOアクションとして合成するのみ）。そのため純粋な関数からI/O関数を呼ぶことは型エラーになり、コンパイラソースコードを解析し、実行可能な形式（機械語や中間表現）に変換するプログラム。静的型付け言語では、実行前にコンパイラが型の不整合などをチェックする役割も担う。が強制する。`unsafePerformIO`という明示的な抜け道はあるが、名前の通り安全性の放棄として扱われる。標準の`IO`は単一のeffectで、ファイル・ネットワーク・乱数などを型レベルで区別しないが、`mtl`や`effectful`などのライブラリでより細かいeffectを型として分離できる。

find_user(Id)

find_user(Id) ->
    db:get(user, Id).

get_user(Id) ->
    find_user(Id). %% 呼べる

`-spec`で型を後付けしDialyzerで検査できるが、effectを表す語彙は用意されていない。並行処理はプロセス間メッセージパッシング（`!`と`receive`）で行うが、これも通常の関数呼び出しとは別構文である一方、I/Oの有無自体を型シグネチャから読み取る手段ではない。

def find_user(id)

def find_user(id) do
  Repo.get(User, id)
end

def get_user(id) do
  find_user(id) # 呼べる
end

`@spec`で型を後付けしDialyzerで検査できるが、effectを表す語彙は用意されていない。並行処理はプロセス間メッセージパッシングで行うが、これも通常の関数呼び出しと同じ構文で書ける。

function findUser(id: UserId): Promise<User>

function findUser(id: UserId): Promise<User> { /* ... */ }

function getUser(id: UserId): User {
  findUser(id); // awaitせずに呼べる。戻り値を無視しても型エラーにならない
  ...
}

非同期処理は`Promise<T>`という型で戻り値に現れ、呼び出し側は`await`を書かないと値を取り出せないが、`await`せずに呼び出すこと自体は型エラーにならない。同期的なI/O（`fs.readFileSync`など）は通常の関数と区別されない。

function findUser(id) { ... }

function findUser(id) {
  return fetch(`/users/${id}`).then(r => r.json());
}

function getUser(id) {
  findUser(id); // 呼べる。async/awaitを付けなくてもよい
}

`async`/`await`はあるが、静的検査がないため、非同期関数を`await`せずに呼んでも実行時までエラーにならない。I/Oかどうかを示す構文自体が存在しない。

function findUser(UserId $id): User

function findUser(UserId $id): User {
    return $db->find($id);
}

function getUser(UserId $id): User {
    return findUser($id); // 呼べる
}

引数・戻り値の型宣言はできるが、effectを示す仕組みは言語にない。

def find_user(id)

def find_user(id)
  DB.find(id)
end

def get_user(id)
  find_user(id) # 呼べる
end

RBSやSorbetで型を後付けできるが、いずれもeffectの分類までは扱わない。

def find_user(id: UserId) -> User: ...

def find_user(id: UserId) -> User:
    return db.query(id)

def get_user(id: UserId) -> User:
    return find_user(id)  # 呼べる。型チェッカーも止めない

`async def`は非同期関数を示すが、型ヒントと同じく強制力がなく、実行時にもI/Oの有無を判別する仕組みはない。