Goの==演算子の仕組みを徹底解説

Leapcell: The Best of Serverless Web Hosting

Go言語における==演算子の詳細分析

概要

Go言語のプログラミングの実践において、==の等価演算子は非常に一般的に使われます。しかし、フォーラムでのやり取りでは、多くの開発者がGo言語における==演算子の結果について混乱していることがしばしば見られます。実際、Go言語が==演算子を扱う際には、特別に注意すべき多くの詳細があります。これらの詳細な問題は日常の開発ではあまり遭遇しないかもしれませんが、一旦遭遇すると深刻なプログラムエラーにつながる可能性があります。この記事では、Go言語における==演算子の関連する内容について体系的かつ詳細に説明し、多くの開発者に強力な助けになることを願っています。

型システム

Go言語のデータ型は以下の4つのカテゴリに分けることができます：

1. 基本型：整数型（例えばint、uint、int8、uint8、int16、uint16、int32、uint32、int64、uint64、byte、runeなど）、浮動小数点数型（float32、float64）、複素数型（complex64、complex128）、および文字列型（string）を含みます。
2. 複合型（集約型）：主に配列と構造体型を含みます。
3. 参照型：スライス（slice）、map、channel、およびポインタを含みます。
4. インターフェース型：例えばerrorインターフェースなど。

強調しておくべきことは、==演算子の主な前提条件は、2つの演算子の型が完全に一致していることです。型が異なる場合は、コンパイルエラーが発生します。

注目すべきことは：

• Go言語には厳格な型システムがあり、C/C++言語のような暗黙の型変換メカニズムはありません。これはコードを書く際に少々面倒かもしれませんが、その後の多くの潜在的なエラーを効果的に回避することができます。
• Go言語では、typeキーワードを使って新しい型を定義することができます。新しく定義された型は、元の型とは異なり、直接比較することはできません。

型をより明確に表示するために、サンプルコードの変数定義ではすべて明示的に型を指定しています。例えば：

package main

import "fmt"

func main() {
    var a int8
    var b int16
    // コンパイルエラー: invalid operation a == b (mismatched types int8 and int16)
    fmt.Println(a == b)
}

このコードでは、aとbの型が異なる（それぞれint8とint16）ため、==比較を試みるとコンパイルエラーが発生します。

もう一つの例：

package main

import "fmt"

func main() {
    type int8 myint8
    var a int8
    var b myint8
    // コンパイルエラー: invalid operation a == b (mismatched types int8 and myint8)
    fmt.Println(a == b)
}

ここでは、myint8の元の型はint8ですが、それらは異なる型に属しており、直接比較するとコンパイルエラーになります。

異なる型における==演算子の具体的な動作

基本型

基本型の比較演算子は比較的シンプルで直接的で、値が等しいかどうかを比較するだけです。例は以下の通り：

var a uint32 = 10
var b uint32 = 20
var c uint32 = 10
fmt.Println(a == b) // false
fmt.Println(a == c) // true

ただし、浮動小数点数の比較を扱う際には特別に注意する必要があります：

var a float64 = 0.1
var b float64 = 0.2
var c float64 = 0.3
fmt.Println(a + b == c) // false

これは、コンピュータでは一部の浮動小数点数が正確に表現できず、浮動小数点数演算の結果にはある程度の誤差が生じるためです。a + bとcの値をそれぞれ出力することで、違いを明確に見ることができます：

fmt.Println(a + b)
fmt.Println(c)
// 0.30000000000000004
// 0.3

この問題はGo言語に特有のものではありません。IEEE 754規格に準拠したすべてのプログラミング言語が、浮動小数点数を扱う際に同様の状況に直面する可能性があります。したがって、プログラミングではできるだけ直接的な浮動小数点数の比較を避けるべきです。本当に比較が必要な場合は、2つの浮動小数点数の差の絶対値を計算することができます。この値が設定された極めて小さな値（例えば1e - 9）よりも小さい場合、それらは等しいとみなすことができます。

複合型

Go言語の複合型（すなわち集約型）は配列と構造体のみです。複合型に対して、==演算子は要素ごと/フィールドごとに比較します。

注目すべきことは、配列の長さはその型の一部です。異なる長さの2つの配列は異なる型に属しており、直接比較することはできません。

配列の場合、各要素の値が順番に比較されます。要素の型が異なる（基本型、複合型、参照型、またはインターフェース型のいずれかである可能性があります）に応じて、対応する型の比較規則に従って比較が判断されます。すべての要素が等しい場合のみ、2つの配列が等しいとみなされます。

構造体の場合、各フィールドの値も順番に比較されます。フィールドの型が属する4つの主要な型カテゴリに応じて、特定の型の比較規則に従います。すべてのフィールドが等しい場合のみ、2つの構造体が等しいとみなされます。

例は以下の通り：

a := [4]int{1, 2, 3, 4}
b := [4]int{1, 2, 3, 4}
c := [4]int{1, 3, 4, 5}
fmt.Println(a == b) // true
fmt.Println(a == c) // false

type A struct {
    a int
    b string
}
aa := A { a : 1, b : "leapcell_test1" }
bb := A { a : 1, b : "leapcell_test1" }
cc := A { a : 1, b : "leapcell_test2" }
fmt.Println(aa == bb) // true
fmt.Println(aa == cc) // false

参照型

参照型は参照するデータを間接的に指し、変数はデータのアドレスを格納します。したがって、参照型の==比較は実際には、2つの変数が同じデータを指しているかどうかを判断するものであり、指している実際のデータ内容を比較するものではありません。

例は以下の通り：

type A struct {
    a int
    b string
}

aa := &A { a : 1, b : "leapcell_test1" }
bb := &A { a : 1, b : "leapcell_test1" }
cc := aa
fmt.Println(aa == bb) // false
fmt.Println(aa == cc) // true

この例では、aaとbbが指す構造体の値は等しい（上記の複合型の比較規則を参照）ものの、それらは異なる構造体インスタンスを指しているため、aa == bbはfalseです；一方、aaとccは同じ構造体を指しているため、aa == ccはtrueです。

channelを例にとる：

ch1 := make(chan int, 1)
ch2 := make(chan int, 1)
ch3 := ch1

fmt.Println(ch1 == ch2) // false
fmt.Println(ch1 == ch3) // true

ch1とch2は同じ型であるものの、それらは異なるchannelインスタンスを指しているため、ch1 == ch2はfalseです；ch1とch3は同じchannelを指しているため、ch1 == ch3はtrueです。

参照型に関して、2つの特別な規則があります：

• スライスは直接比較することが許可されていません。スライスはnil値との比較のみが可能です。
• mapは直接比較することが許可されていません。mapはnil値との比較のみが可能です。

スライスが直接比較されることが許可されていない理由は以下の通りです：参照型としてのスライスは、自分自身を間接的に指す可能性があります。例えば：

a := []interface{}{ 1, 2.0 }
a[1] = a
fmt.Println(a)
// !!!
// runtime: goroutine stack exceeds 1000000000 - byte limit
// fatal error: stack overflow

上記のコードではaをa[1]に代入しているため、再帰的な参照が発生し、fmt.Println(a)文を実行するとスタックオーバーフローエラーが発生します。スライスの参照アドレスを直接比較すると、一方では配列の比較方法と大きく異なり、開発者を混乱させる可能性があります；もう一方では、スライスの長さと容量はその型の一部であり、異なる長さと容量のスライスに対して統一的な比較規則を決定することは困難です。スライスの中の要素を配列のように比較すると、循環参照の問題に直面することになります。この問題は言語レベルで解決することはできますが、Go言語の開発チームはこれにあまり多くの努力を払う価値はないと考えています。以上の理由から、Go言語ではスライス型が直接比較できないことが明確に規定されており、==を使ってスライスを比較すると直接コンパイルエラーになります。例えば：

var a []int
var b []int

// invalid operation: a == b (slice can only be compared to nil)
fmt.Println(a == b)

エラーメッセージは明確に、スライスはnil値との比較のみが可能であることを示しています。

map型の場合、その値の型が比較不能な型（例えばスライス）である可能性があるため、map型も直接比較することはできません。

インターフェース型

インターフェース型はGo言語において重要な役割を果たします。インターフェース型の値、すなわちインターフェース値は、2つの部分で構成されます：特定の型（すなわちインターフェースに格納される値の型）とその型の値。言い換えれば、それぞれ動的型と動的値と呼ばれます。インターフェース値の比較は、この2つの部分の比較を伴います。動的型が完全に一致し、動的値が等しい（動的値は==を使って比較されます）場合のみ、2つのインターフェース値が等しいとみなされます。

例は以下の通り：

var a interface{} = 1
var b interface{} = 1
var c interface{} = 2
var d interface{} = 1.0
fmt.Println(a == b) // true
fmt.Println(a == c) // false
fmt.Println(a == d) // false

この例では、aとbの動的型は同じ（どちらもint）で、動的値も同じ（どちらも1で、基本型の比較に属します）ため、a == bはtrueです；aとcの動的型は同じですが、動的値は等しくない（それぞれ1と2）ため、a == cはfalseです；aとdの動的型は異なる（aはintで、dはfloat64）ため、a == dはfalseです。

構造体をインターフェース値として使う場合を見てみましょう：

type A struct {
    a int
    b string
}

var aa interface{} = A { a: 1, b: "test" }
var bb interface{} = A { a: 1, b: "test" }
var cc interface{} = A { a: 2, b: "test" }

fmt.Println(aa == bb) // true
fmt.Println(aa == cc) // false

var dd interface{} = &A { a: 1, b: "test" }
var ee interface{} = &A { a: 1, b: "test" }
fmt.Println(dd == ee) // false

aa と bb の動的型は同じ（どちらも A）で、動的値も同じ（上記の複合型における構造体の比較規則による）ため、aa == bb は true です。aa と cc の動的型は同じですが、動的値が異なるため、aa == cc は false です。dd と ee の動的型は同じ（どちらも *A）で、動的値はポインタ（参照）型の比較規則を使います。同じアドレスを指していないため、dd == ee は false です。

注意すべきは、インターフェースの動的値が比較不能な場合、強制的に比較すると panic が発生します。例えば：

var a interface{} = []int{1, 2, 3, 4}
var b interface{} = []int{1, 2, 3, 4}
// panic: runtime error: comparing uncomparable type []int
fmt.Println(a == b)

ここでは、a と b の動的値はスライス型で、スライス型は比較不能です。そのため、a == b を実行すると panic がトリガーされます。

また、インターフェース値の比較では、インターフェース型（動的型ではないことに注意）が完全に一致する必要はありません。一方のインターフェースがもう一方のインターフェースに変換できる限り、比較が可能です。例えば：

var f *os.File

var r io.Reader = f
var rc io.ReadCloser = f
fmt.Println(r == rc) // true

var w io.Writer = f
// invalid operation: r == w (mismatched types io.Reader and io.Writer)
fmt.Println(r == w)

r の型は io.Reader インターフェースで、rc の型は io.ReadCloser インターフェースです。ソースコードを見ると、io.ReadCloser の定義は以下の通りです：

type ReadCloser interface {
    Reader
    Closer
}

io.ReadCloser は io.Reader に変換できるため、r と rc は比較できます。一方、io.Writer は io.Reader に変換できないため、コンパイルエラーが発生します。

type で定義された型

type キーワードを使って既存の型を基に定義された新しい型については、その元の型に従って比較が行われます。例えば：

type myint int
var a myint = 10
var b myint = 20
var c myint = 10
fmt.Println(a == b) // false
fmt.Println(a == c) // true

type arr4 [4]int
var aa arr4 = [4]int{1, 2, 3, 4}
var bb arr4 = [4]int{1, 2, 3, 4}
var cc arr4 = [4]int{1, 2, 3, 5}
fmt.Println(aa == bb) // true
fmt.Println(aa == cc) // false

ここでは、myint 型は元の型 int に従って比較され、arr4 型は元の型 [4]int に従って比較されます。

比較不能性とその影響

前述の通り、Go言語のスライス型は比較不能です。これにより、スライスを含むすべての型も比較不能になります。具体的には、以下のものが該当します：

• 配列の要素がスライス型である。
• 構造体がスライス型のフィールドを含む。
• ポインタがスライス型を指す。

比較不能性は推移的です。構造体がスライスフィールドを含むために比較不能である場合、それを要素とする配列も比較不能であり、それをフィールド型とする構造体も比較不能です。

map と比較不能な型の関係

map のキーバリューペアは == 演算子を使って等価判定を行うため、すべての比較不能な型は map のキーとして使うことができません。例えば：

// invalid map key type []int
m1 := make(map[[]int]int)

type A struct {
    a []int
    b string
}
// invalid map key type A
m2 := make(map[A]int)

上記のコードでは、スライス型が比較不能であるため、m1 := make(map[[]int]int) はコンパイルエラーを報告します。構造体 A はスライスフィールドを含むため比較不能であり、これも m2 := make(map[A]int) がコンパイルエラーを報告する原因となります。

まとめ

この記事では、Go言語における == 演算子の詳細を包括的かつ詳細に紹介しました。異なるデータ型における == 演算子の動作、特殊な型の比較規則、および比較不能な型による影響をカバーしています。この記事の説明を通じて、多くの開発者がGo言語の == 演算子をより正確かつ深く理解し、適用するのに役立ち、実際のプログラミングでの理解不足による様々な問題を回避することができることを願っています。

Leapcell: The Best of Serverless Web Hosting

最後に、Goサービスのデプロイに最適なプラットフォームをおすすめします：Leapcell

🚀 好きな言語で構築

JavaScript、Python、Go、またはRustで楽に開発できます。

🌍 無制限のプロジェクトを無料でデプロイ

使用した分だけ支払います。リクエストがなければ料金はかかりません。

⚡ 従量課金制、隠れたコストは一切ありません

アイドル料金はなく、シームレスなスケーラビリティが提供されます。

📖 ドキュメントを探索する

🔹 Twitterでフォローしましょう：@LeapcellHQ