関数の引数

fn f(s: &String) / fn f(s: &mut String) / fn f(s: String)

fn len(s: &String) -> usize { s.len() }   // 借用（読み取り専用）
fn push(s: &mut String) { s.push('a'); }  // 可変借用
fn take(s: String) {}                      // 所有権を受け取る

let mut s = String::from("a");
len(&s);       // 呼び出し側にも & が付く
push(&mut s);  // 可変であることも呼び出し側で分かる
take(s);       // moveは呼び出し側に印がない。以降sは使えない

引数の渡し方が「借用所有権を移さずに、値を一時的に貸し出して使わせること。Rustでは`&T`（読み取り専用）と`&mut T`（変更可能）で表し、借りている間の書き換えや破棄をコンパイラが検査する。するか、所有権値の持ち主を一つに定め、持ち主がいなくなったときに値を破棄する仕組み。Rustが代表例で、値を別の変数や関数へ渡すと持ち主が移り（move）、元の変数は使えなくなる。を移すか、変更を許すか」を型として表す。借用所有権を移さずに、値を一時的に貸し出して使わせること。Rustでは`&T`（読み取り専用）と`&mut T`（変更可能）で表し、借りている間の書き換えや破棄をコンパイラが検査する。は呼び出し側にも`&` / `&mut`が付くが、moveは印がなく、変数が消費されることは関数の定義を見ないと分からない。所有権値の持ち主を一つに定め、持ち主がいなくなったときに値を破棄する仕組み。Rustが代表例で、値を別の変数や関数へ渡すと持ち主が移り（move）、元の変数は使えなくなる。と可変性を安全に扱うための仕組みであり、どちらも扱わないmelangでは採用しない。

fn f(n : Int, arr : Array[Int]) -> Unit

fn f(n : Int, arr : Array[Int]) -> Unit {
  // n = 1  // 引数は再代入できない
  arr.push(n) // 渡されたArrayの中身は変更できる
}

fn g(r : Ref[Int]) -> Unit {
  r.val = 1
}

引数は不変で、書き換えたい場合は`Ref[T]`や可変な`Array`など、可変な型の値を渡す。渡し方を選ぶ構文はなく、可変性は型で表される。OCamlと同じ方針で、呼び出し側には印が付かない。

func f(_ x: inout Int) / func f(_ x: borrowing T) / func f(_ x: consuming T)

func a(_ n: Int) {}
func b(_ n: inout Int) { n += 1 }
func c(_ t: borrowing Token) {}  // 借用（コピー不能な型向け）
func d(_ t: consuming Token) {}  // 消費（所有権を受け取る）

var n = 0
a(n)
b(&n) // 呼び出し側に & が付く

引数は不変で、書き換えを許す`inout`は呼び出し側にも`&`を付けて示す。呼び出しを読むだけで、書き換えられる可能性が分かる。melangは、書き換え自体をなくすことで同じ読みやすさを得る。Swift 5.9以降は`borrowing` / `consuming`で所有権値の持ち主を一つに定め、持ち主がいなくなったときに値を破棄する仕組み。Rustが代表例で、値を別の変数や関数へ渡すと持ち主が移り（move）、元の変数は使えなくなる。に近い渡し方も表せるが、こちらは呼び出し側に印が要らない。

fun f(n: Int, list: MutableList<Int>)

fun f(n: Int, list: MutableList<Int>) {
    // n = 1     // 引数は再代入できない（コンパイルエラー）
    list.add(1) // 渡されたオブジェクトの中身は変更できる
}

引数は常に`val`相当で再代入できないため、引数自体を書き換えて呼び出し側に影響を与える事故は防げる。一方で、可変なコレクションを渡せば中身は変更できる。melangの「代入そのものを禁止する」方向と近く、引数を共有して渡す点も同じ。ただしmelangは、オブジェクトの中身も不変にする。

void f(int n, StringBuilder sb)

void f(int n, StringBuilder sb) {
    n = 1;          // 呼び出し側には影響しない
    sb.append("a"); // 呼び出し側から見える（同じオブジェクト）
}

引数はすべて値渡しだが、オブジェクトの場合は参照の値がコピーされるため、中身を書き換えると呼び出し側から見える。「値渡しなのに参照のように見える」という誤解を招きやすい。渡し方を選ぶ構文はなく、呼び出し側にも印はない。melangの渡し方はこれに近いが、オブジェクトが不変なので、共有された中身を書き換えられることはない。

def f(x: Int) / def f(x: => Int)

def a(n: Int) = n + n        // 呼び出し時に一度だけ評価される
def b(n: => Int) = n + n     // 名前渡し。使うたびに評価される

a({ println("x"); 1 })  // "x"は1回
b({ println("x"); 1 })  // "x"は2回

引数は不変で、参照渡しは無い。`=>`による名前渡しは、コピーか参照かではなく「いつ評価するか」を選ぶ仕組みで、melangが扱う「コピーか共有か」とは別の軸。可変なコレクションを渡せば中身を変更できる点はJava・Kotlinと同じ。

void F(ref int x) / void F(out int x) / void F(in T x)

void A(int n) {}
void B(ref int n) { n++; }
void C(out int n) { n = 1; }
void D(in BigStruct s) {}

int x = 0;
A(x);
B(ref x);  // 呼び出し側にも ref が必要
C(out x);  // 呼び出し側にも out が必要
D(in s);   // in は呼び出し側では省略できる

`ref` / `out`は、定義側と呼び出し側の両方にキーワードを書かないとコンパイルエラーになる。呼び出しを読むだけで、変数が書き換えられる可能性が分かる。書き換えの可能性を呼び出し側に明示する先行例。melangは書き換え自体をなくすため、この印が要らない。ただし`in`は呼び出し側で省略でき、通常の値渡しには印がない。

void f(T x) / void f(const T& x) / void f(T& x) / void f(T&& x)

void a(std::string s);        // コピー
void b(const std::string& s); // 読み取り専用の参照
void c(std::string& s);       // 変更可能な参照
void d(std::string&& s);      // 右辺値参照（moveの受け口）

std::string s = "a";
a(s);  // 呼び出し側の見た目は
b(s);  // どれも同じで、
c(s);  // 関数の宣言を見ないと違いが分からない
d(std::move(s));

渡し方を最も細かく選べる一方、`a(s)`と`c(s)`は呼び出し側では同じ見た目になる。変数が書き換えられるかは宣言を確認するまで分からず、書き換えの可能性が呼び出し側から見えないという問題は、値を不変にして代入を禁止するmelangでは、そもそも起きない。

void f(int x); / void f(int *p);

void a(int n) { n = 1; }   // 呼び出し側には影響しない
void b(int *p) { *p = 1; } // ポインタ経由で書き換える

int n = 0;
a(n);
b(&n); // 呼び出し側にも & が付く

void c(int arr[]) { arr[0] = 1; } // 配列は関数に渡す時点でポインタへ「減衰」する

引数はすべて値渡しで、参照的に扱いたければアドレスを明示的にポインタとして渡す。Goの「値渡し＋明示的なポインタ」はこの設計をほぼそのまま受け継ぎ、C++の参照（`T&`）はポインタを安全に隠す糖衣構文として追加されたものである。配列を関数に渡すと先頭要素へのポインタに「減衰（decay）」するため、関数側では元の配列のサイズを知る手段がなく、別途サイズを渡す必要がある。このサイズ情報を失うポインタ渡しはバッファオーバーランの主要な原因の一つであり、後発言語がスライスや境界チェック付き配列を導入する動機になった。

func f(x int) / func f(p *int)

func a(n int) { n = 1 }   // 呼び出し側には影響しない
func b(p *int) { *p = 1 } // ポインタ経由で書き換える

n := 0
a(n)
b(&n) // 呼び出し側に & が付く

// スライスやmapは、ヘッダ自体がコピーされるが中身は共有される

引数はすべて値渡しで、参照的に扱いたければポインタを渡す。ポインタの受け渡しは呼び出し側にも`&`が付くため、書き換えられる可能性が読み取れる。ただしスライスやmapは値渡しでも中身を共有するため、渡し方が型によって分かりにくくなる。

fn f(x: i32) void / fn f(p: *i32) void / fn f(items: []i32) void

fn a(n: i32) void {
    // n = 1; // コンパイルエラー：引数は既定でconst
    var m = n;
    m += 1; // 変更したい場合はローカルのvarへ明示的にコピーする
}

fn b(p: *i32) void {
    p.* += 1; // ポインタ経由で書き換える
}

var x: i32 = 0;
a(x);
b(&x); // 呼び出し側に & が付く

fn c(items: []i32) void {
    items[0] = 9; // スライスは(ポインタ, 長さ)の組で、中身は共有される
}

引数は既定で値渡しかつ関数内では不変（const相当）で、書き換えたい場合はローカルの`var`へ明示的にコピーする必要がある。ポインタ・スライスで受け取れば呼び出し側の値を書き換えられ、呼び出し側にも`&`が付く点はGo/Cと同じ。struct/arrayのような大きな集約型は、意味論上は値渡し（コピー）として扱われるが、コンパイラソースコードを解析し、実行可能な形式（機械語や中間表現）に変換するプログラム。静的型付け言語では、実行前にコンパイラが型の不整合などをチェックする役割も担う。がABIレベルの最適化として実体を参照渡しに置き換えることがある——これは言語仕様ではなく実装上の最適化であり、呼び出し側から見える意味論（値が共有されないこと）には影響しない。allocationが必要な標準ライブラリ関数はallocatorを明示的な引数として受け取る慣習があり、隠れたメモリ確保を避ける設計思想の一部になっている。

let f (r : int ref) = r := !r + 1

let f x = x + 1                  (* 値渡し。xは不変 *)
let incr_ref (r : int ref) = r := !r + 1

let c = ref 0
let () = incr_ref c              (* 呼び出し側は普通の値渡しに見える *)

引数の渡し方を選ぶ構文はなく、書き換えたいときは`ref`型（可変セル）の値を渡す。渡し方ではなく、値の型で可変性を表す設計。呼び出し側は普通の値渡しと見た目が変わらないが、`ref`型の変数を渡していることは型を見れば分かる。可変なデータを持つ設計であり、melangでは採用しない。

let f (r : int ref) = r := !r + 1

let f x = x + 1                  // 値渡し。xは不変
let incrRef (r : int ref) = r.Value <- r.Value + 1

let c = ref 0
incrRef c                        // 呼び出し側は普通の値渡しに見える

let incrByref (x : byref<int>) = x <- x + 1
let mutable n = 0
incrByref &n                     // .NET由来のbyrefは呼び出し側に&が必要

OCamlの`ref`型をそのまま受け継ぎ、書き換えたいときはref型（可変セル）の値を渡す設計が基本。加えて.NETとの相互運用のため`byref<T>`引数も使え、こちらはC#の`ref`同様、呼び出し側にも`&`を書く必要がある。同じ言語の中に「印がない可変性（ref型）」と「印がある可変性（byref）」が両方存在する点が特徴。

f :: Int -> Int

f :: [Int] -> [Int]
f xs = 1 : xs   -- 元のxsは変わらない。共有するかコピーするかは処理系が決める

g :: Int -> Int
g !x = x + 1    -- BangPatterns。引数を即座に評価する

値がすべて不変なので、コピーか参照かはプログラムの結果に影響せず、処理系が決める。melangの「変更可能なデータが存在しない」前提に最も近い言語。melangはこの前提に、Java・Kotlinと同じ「常に共有して渡す」仕様を組み合わせ、コストを予測しやすくする。

f(List)

f(List) -> [1 | List].  %% 元のListは変わらない

Xs = [2, 3],
Ys = f(Xs),
%% Xs =:= [2, 3]
%% Ys =:= [1, 2, 3]

%% プロセス間で送るときは値がコピーされる
Pid ! {self(), Xs}.

値はすべて不変で、通常の関数呼び出しは同一プロセス内で値を共有して渡すため、渡し方を選ぶ構文はない。一方、プロセス間でメッセージ（`!`）として送るときは、共有メモリを持たないプロセスモデルのため値がコピーされる。「関数呼び出しの引数」と「プロセス間メッセージ」で共有かコピーかが変わる点が、単一プロセスのHaskell・Elixirとの違い。

def f(list)

def f(list), do: [1 | list]  # 元のlistは変わらない

xs = [2, 3]
ys = f(xs)
# xs == [2, 3]
# ys == [1, 2, 3]

値がすべて不変で、変数の再束縛も呼び出し側には影響しない。同一プロセス内では値が共有され、プロセス間では値がコピーされる、といった扱いは処理系が決める。Haskellと同じく、melangの「変更可能なデータが存在しない」前提に近い。

function f(n: number, obj: { v: number })

function f(n: number, obj: { v: number }) {
  n = 1;     // 呼び出し側には影響しない
  obj.v = 1; // 呼び出し側から見える
}

function g(obj: Readonly<{ v: number }>) {
  // obj.v = 1; // 型検査でエラー
}

JavaScriptと同じ挙動で、渡し方を選ぶ構文はない。`Readonly`型で型検査上は書き換えを禁じられるが、実行時の挙動は変わらない。プリミティブとオブジェクトで扱いが変わるため、型を見ないと渡し方が分からない。

function f(n, obj)

function f(n, obj) {
  n = 1;     // 呼び出し側には影響しない
  obj.v = 1; // 呼び出し側から見える
}

const o = { v: 0 };
f(0, o);
console.log(o.v); // 1

プリミティブは値が渡され、オブジェクトは参照の値が渡される。引数の再代入は呼び出し側に影響しないが、オブジェクトの中身の変更は影響する。渡し方を選ぶ構文はなく、値の種類によって暗黙に決まる。

function f(&$x)

function a($n) { $n = 1; }
function b(&$n) { $n = 1; }

$x = 0;
a($x); // $xは0のまま
b($x); // $xが1になる。呼び出し側は見た目が同じ

定義側に`&`を付けると参照渡しになるが、呼び出し側は印が要らない。`a($x)`と`b($x)`が同じ見た目で、変数が書き換わるかは関数の定義を見ないと分からない。かつては呼び出し側に`&`を書ける仕組みもあったが、現在は廃止されている。

def f(n, s)

def f(n, s)
  n += 1      # 再代入は呼び出し側に影響しない
  s << "a"    # 破壊的メソッドは呼び出し側から見える
end

str = +"x"
f(0, str)
puts str # "xa"

Pythonと同様に、オブジェクトへの参照が渡される。再代入は呼び出し側に影響しないが、破壊的メソッド（`<<`, `!`付きのメソッドなど）は影響する。`freeze`で不変にできるが、渡し方としては指定できない。

def f(n, items):

def f(n, items):
    n = 1            # 呼び出し側には影響しない（再束縛）
    items.append(1)  # 呼び出し側から見える（同じlist）

xs = []
f(0, xs)
print(xs)  # [1]

「オブジェクト参照渡し」と呼ばれ、値渡しとも参照渡しとも言い切れない。同じ引数でも、`int`や`str`のような不変な型は影響せず、`list`や`dict`のような可変な型は影響する。可変か不変かを知らないと、呼び出しの結果を予測できない。