暗黙の型変換

let x: i32 = 10;

let x: i32 = 10;
let y: i64 = x; // コンパイルエラー
let y: i64 = x as i64; // OK
let y: i64 = i64::from(x); // OK（Fromで安全性が保証される変換）

i32からi64のような拡大変換であっても暗黙には行われず、`as`や`From`/`Into`による明示が必須。`as`は情報を失う変換も許すが、`From`は失敗しない変換にのみ実装される、というように変換の安全性を型で区別している。

let x : Int = 10

let x : Int = 10
let y : Double = x               // 型エラー
let y : Double = x.to_double()   // OK

Rust/Kotlinに近い設計思想で、数値型間の暗黙変換を持たない。`to_double()`のような明示的な変換メソッドを呼ぶ必要がある。

let x: Int = 10

let x: Int = 10
let y: Double = x        // コンパイルエラー
let y: Double = Double(x) // OK

数値型間の暗黙変換を持たず、`Int`と`Double`を混在させる演算もコンパイルエラーになる。`Double(x)`のようにイニシャライザを介した明示的な変換が必要。

val x: Int = 10

val x: Int = 10
val y: Long = x          // コンパイルエラー
val y: Long = x.toLong() // OK

Javaと異なり、Kotlinは拡大変換であっても数値型間の暗黙変換を行わない。`toLong()`, `toDouble()`のような明示的な変換メソッドを必ず呼ぶ設計で、melangが目指す方針に最も近い言語の一つ。

int x = 10;

int x = 10;
long y = x; // 暗黙にlongへ拡大変換される

long a = 10;
int b = 20;
long c = a + b; // bがlongへ暗黙変換されてから加算される

short s = (short) x; // 縮小変換にはキャストが必要

intからlong、floatからdoubleのような「情報を失わない」拡大変換（widening）は暗黙に行われる。逆に縮小変換（narrowing）は明示的なキャストを要求する。二項演算子のオペランドも、大きい方の型に暗黙に合わせられる（binary numeric promotion）。

val x: Int = 10

val x: Int = 10
val y: Long = x   // 暗黙にLongへ拡大変換される
val z: Double = x // Int -> Double も暗黙変換される

Javaと同様、IntからLong、FloatからDoubleのような拡大変換は暗黙に行われる。さらに`implicit def`（Scala 3では`given`によるconversion）でユーザー定義の暗黙変換を追加できるが、`scala.language.implicitConversions`の明示的な有効化を要求するなど、濫用への注意喚起がされている。

int x = 10;

int x = 10;
long y = x;          // 暗黙にlongへ拡大変換される
short s = (short) x; // 縮小変換にはキャストが必要

intからlong、floatからdoubleのような拡大変換は暗黙に行われる。ユーザー定義型でも`implicit operator`を定義すれば独自の暗黙変換を組み込める。縮小変換は明示的なキャストが必要。

int x = 10;

int x = 10;
long y = x;   // 暗黙変換でOK
double z = x; // int -> double も暗黙変換される
short s = x;  // 縮小変換も警告のみで通ることが多い

算術型間の標準変換（整数昇格・浮動小数点変換など）が広く暗黙に行われる。縮小変換（intからshortなど）も多くの場合は警告止まりでコンパイルが通り、意図しない情報欠落が起きやすい。ユーザー定義型でも変換コンストラクタやconversion operatorにより暗黙変換を定義できる（`explicit`で抑制可能）。

int x = 10;

int x = 10;
long y = x;   // 暗黙変換でOK
double z = x; // int -> double も暗黙変換される

int a = -1;
unsigned int b = 3;
if (a < b) { /* 実行されない: aがunsignedへ暗黙変換され巨大な値になる */ }

算術型間の暗黙変換（integer promotion / usual arithmetic conversions）が広く働き、C++はこれをそのまま受け継いでいる。特にsignedとunsignedを混在させる比較・演算では、signedの値が暗黙にunsignedへ変換されるため`-1 < 3u`が偽になるといった直感に反する挙動が起き、実務上のバグの温床として知られる。この危険な暗黙変換の存在が、KotlinやSwiftのように数値型間の暗黙変換を一切禁止する設計への反面教師になっている。

var x int32 = 10

var x int32 = 10
var y int64 = x        // コンパイルエラー
var y int64 = int64(x) // OK

int32からint64のような安全な拡大変換であっても暗黙には行われず、必ず`T(x)`という形の明示的な変換を書く。

const x: i32 = 10;

const x: i32 = 10;
const y: i64 = x;            // コンパイルエラー：runtime値は暗黙変換されない
const y: i64 = @intCast(x);  // OK

const z: i64 = 10; // OK：10はcomptime_intなので変換先の型に自動でcoerceされる

実行時に決まる値同士の数値型間ではRust/Goと同様に暗黙変換を持たず、i32からi64のような拡大変換であっても`@intCast`などのbuiltinで明示する必要がある。一方、リテラルのようなcomptime_int/comptime_float型のcomptime-known値は、収まる範囲であれば変換先の型へ自動的にcoerceされる。さらにif/elseの各分岐や配列・スライスの型を揃えるpeer type resolutionという別の仕組みもあり、「暗黙変換が一切ない」と単純化はできない。

let x : int = 10

let x : int = 10
let y : float = x (* 型エラー *)
let y : float = float_of_int x (* OK *)

let a = 1 + 2      (* int の加算 *)
let b = 1.0 +. 2.0 (* float の加算は別の演算子 *)

数値型間の暗黙変換を一切持たない徹底した設計で、intとfloatの加算にも別の演算子（`+`と`+.`）を使い分ける必要があるほど厳格。変換には`float_of_int`, `int_of_float`のような専用関数を使う。

let x : int = 10

let x : int = 10
let y : float = x   // コンパイルエラー
let y : float = float x // OK

OCamlを受け継ぎ、intからfloatのような一方向の変換であっても暗黙には行われない。ただし`+.`のような別演算子は持たず、`+`は数値の型を静的に確定できれば`int`・`float`のどちらにも使える（演算子オーバーロードによる静的多相）ため、演算子自体を使い分ける必要はOCamlより薄い。変換には`float x`, `int64 x`のような組み込みの変換演算子を使う。

x :: Int
x = 10

x :: Int
x = 10

y :: Integer
y = x             -- 型エラー
y = fromIntegral x -- OK

数値型間の暗黙変換はなく、`Int`から`Integer`、`Int`から`Double`のような変換にも`fromIntegral`や`realToFrac`のような明示的な変換関数を要求する。数値リテラル自体は`Num`型クラスにより多相的に扱われるが、これは既存の値を変換する話とは別の仕組み。

X = 10.

X = 10,
Y = 1.5,
X + Y.   %% 11.5（integerがfloatへ暗黙変換される）
X + "5". %% badarith（数値と文字列の暗黙変換はない）

integerとfloatを混在させる算術演算では暗黙に型が揃えられるが、それ以外の型（文字列・アトムなど）との暗黙変換は行われない。ガード節（`is_integer`など）で型を明示的に確認するスタイルが基本で、Elixirもこの挙動をそのまま受け継いでいる。

x = 10

x = 10
y = 1.5
x + y   # 11.5（integerがfloatへ暗黙変換される）
x + "5" # ArithmeticError（数値と文字列の暗黙変換はない）

integerとfloatを混在させる算術演算では暗黙に型が揃えられるが、それ以外の型（文字列など）との暗黙変換は行われない。パターンマッチやガード節で型を明示的に扱うスタイルが基本。

let x: number = 10;

let x: number = 10;
let y: string = x; // 型エラー

let a: number = 10;
let b: string = "20";
a + b; // 型エラー（算術演算子のオペランドはnumber/bigintを要求）

静的な型検査上は数値と文字列などの間の暗黙変換を許さない。ただし型検査を通過してJavaScriptとして実行される段階では、`+`演算子など実行時の暗黙変換自体は残っており、「型システム上の暗黙変換」と「実行時の暗黙変換」が分離しているのが特徴。

let x = 10;

let x = 10;
x + "1"; // "101"（数値が文字列に暗黙変換されて結合される）
"5" - 2; // 3（文字列が数値に暗黙変換される）

演算子ごとに異なる規則でオペランドの型を暗黙に変換する。`+`は片方が文字列なら文字列結合、`-`などは数値変換を試みるといったように規則が演算子ごとに異なり、意図しない挙動の温床になりやすい。

$x = 10;

$x = 10;
$x + "5abc"; // 15（文字列が数値へ暗黙変換される）
$x == "10";  // true（==は型を揃えてから比較する）

数値と数値形式の文字列との間でも暗黙変換が広く行われ、`==`のような比較演算子でも型が揃えられてから比較される。`declare(strict_types=1)`や`===`を使うことで暗黙変換を抑制できるが、デフォルトでは緩い。

x = 10

x = 10
y = 1.5
x + y   # 2.5（IntegerがFloatへ暗黙変換される）
x + "5" # TypeError（数値と文字列の暗黙変換はない）

Integer/Floatのような数値型同士の演算では暗黙に型を揃えるが、数値と文字列のような異なる種類の型を混ぜるとTypeErrorになる。ユーザー定義クラスでも`coerce`メソッドを実装すれば数値との暗黙変換に参加できる。

x = 10

x = 10
y = 1.5
x + y   # 3.5（intがfloatへ暗黙変換されて演算される）
x + "1" # TypeError（数値と文字列の暗黙変換はない）

数値の型階層（int -> float -> complex）内では暗黙変換が行われるが、数値と文字列のような異なる種類の型の間では暗黙変換は起きず、実行時にエラーになる。