Value Conversion, Assignment and Comparison Rules in Go

For example,

• values of type byte and uint8 can be converted to each other.
• values of type rune and int32 can be converted to each other.
• values of type []byte and []uint8 can be converted to each other.

An example:

package main

func main() {
	// []int, IntSlice and MySlice share
	// the same underlying type: []int
	type IntSlice []int
	type MySlice  []int
	type Foo = struct{n int `foo`}
	type Bar = struct{n int `bar`}

	var s  = []int{}
	var is = IntSlice{}
	var ms = MySlice{}
	var x map[Bar]Foo
	var y map[Foo]Bar

	// The two implicit conversions both doesn't work.
	/*
	is = ms // error
	ms = is // error
	*/

	// Must use explicit conversions here.
	is = IntSlice(ms)
	ms = MySlice(is)
	x = map[Bar]Foo(y)
	y = map[Foo]Bar(x)

	// Implicit conversions are okay here.
	s = is
	is = s
	s = ms
	ms = s
}

Pointer related conversion example:

package main

func main() {
	type MyInt int
	type IntPtr *int
	type MyIntPtr *MyInt

	var pi = new(int)  // the type of pi is *int
	// ip and pi have the same underlying type,
	// and the type of pi is unnamed, so
	// the implicit conversion works.
	var ip IntPtr = pi

	// var _ *MyInt = pi // can't convert implicitly
	var _ = (*MyInt)(pi) // ok, must explicitly

	// Values of *int can't be converted to MyIntPtr
	// directly, but can indirectly.
	/*
	var _ MyIntPtr = pi  // can't convert implicitly
	var _ = MyIntPtr(pi) // can't convert explicitly
	*/
	var _ MyIntPtr = (*MyInt)(pi)  // ok
	var _ = MyIntPtr((*MyInt)(pi)) // ok

	// Values of IntPtr can't be converted to
	// MyIntPtr directly, but can indirectly.
	/*
	var _ MyIntPtr = ip  // can't convert implicitly
	var _ = MyIntPtr(ip) // can't convert explicitly
	*/
	var _ MyIntPtr = (*MyInt)((*int)(ip))  // ok
	var _ = MyIntPtr((*MyInt)((*int)(ip))) // ok
}

Example:

package main

func main() {
	type C chan string
	type C1 chan<- string
	type C2 <-chan string

	var ca C
	var cb chan string

	cb = ca // ok, same underlying type
	ca = cb // ok, same underlying type

	// The 4 lines compile okay for this 3rd rule.
	var _, _ chan<- string = ca, cb // ok
	var _, _ <-chan string = ca, cb // ok
	var _ C1 = cb                   // ok
	var _ C2 = cb                   // ok

	// Values of C can't be converted
	// to C1 and C2 directly.
	/*
	var _ = C1(ca) // compile error
	var _ = C2(ca) // compile error
	*/

	// Values of C can be converted
	// to C1 and C2 indirectly.
	var _ = C1((chan<- string)(ca)) // ok
	var _ = C2((<-chan string)(ca)) // ok
	var _ C1 = (chan<- string)(ca)  // ok
	var _ C2 = (<-chan string)(ca)  // ok
}

Example:

package main

func main() {
	var _ []int = nil
	var _ map[string]int = nil
	var _ chan string = nil
	var _ func()() = nil
	var _ *bool = nil
	var _ interface{} = nil

	var _ int = 123.0
	var _ float64 = 123
	var _ int32 = 1.23e2
	var _ int8 = 1 + 0i
}

Example:

package main

func main() {
	// The implicit conversions are all legal.
	const I = 123
	const I1, I2 int8 = 0x7F, -0x80
	const I3, I4 int8 = I, 0.0
	const F = 0.123456789
	const F32 float32 = F
	const F32b float32 = I
	const F64 float64 = F
	const C1, C2 complex64 = F, I
	
	// const F64b float64 = I3 // doesn't compile
	const F64b = float64(I3)   // compiles okay
	
	// const I5 int = C2 // doesn't compile
	const I5 = int(C2)   // compiles okay
}

Note,

• Complex non-constant values can't be converted to floating-point and integer types.
• Floating-point and integer non-constant values can't be converted to complex types.
• Data overflow and rounding are allowed in non-constant number conversions. When converting a floating-point non-constant number to an integer, the fraction is discarded (truncation towards zero).

An example:

package main

import "fmt"

func main() {
	var a, b = 1.6, -1.6 // both are float64
	fmt.Println(int(a), int(b)) // 1 -1

	var i, j int16 = 0x7FFF, -0x8000
	fmt.Println(int8(i), uint16(j)) // -1 32768

	var c1 complex64 = 1 + 2i
	var _ = complex128(c1)
}

Go specification states:

So, the comparison rule is much like the assignment rule. In other words, two values are comparable if one of them can be implicitly converted to the type of the other. Right? Almost, for there is another rule which has a higher priority than the above basic comparison rule.

By the above rule, if an incomparable type (which must be a non-interface type) implements an interface type, then it is illegal to compare values of the two types, even if values of the former (non-interface) type can be implicitly converted to the latter (interface) type.

Note, although values of slice/map/function types don't support comparisons, they can be compared with untyped nil values (a.k.a., bare nil identifiers).

The above described basic rules don't cover all cases. What about if both of the two operands in a comparison are untyped (constant) values? The additional rules are simple:

• untyped boolean values can be compared with untyped boolean values.
• untyped numeric values can be compared with untyped numeric values.
• untyped string values can be compared with untyped string values.

The results of comparing two untyped numeric values obey intuition.

Note, an untyped nil value can't be compared with another untyped nil value.

Any comparison results in an untyped boolean value.

The following example shows some incomparable types related comparisons.

package main

// Some variables of incomparable types.
var s []int
var m map[int]int
var f func()()
var t struct {x []int}
var a [5]map[int]int

func main() {
	// The following lines fail to compile.
	/*
	_ = s == s
	_ = m == m
	_ = f == f
	_ = t == t
	_ = a == a
	_ = nil == nil
	_ = s == interface{}(nil)
	_ = m == interface{}(nil)
	_ = f == interface{}(nil)
	*/

	// The following lines compile okay.
	_ = s == nil
	_ = m == nil
	_ = f == nil
	_ = 123 == interface{}(nil)
	_ = true == interface{}(nil)
	_ = "abc" == interface{}(nil)
}

Assume two values are comparable, and they have the same type T. (If they have different types, one of them must be implicitly convertible to the type of the other. Here we don't consider the cases in which both the two values are untyped.)

1. If T is a boolean type, then the two values are equal only if they are both true or both false.
2. If T is an integer type, then the two values are equal only if they have the same representation in memory.
3. If T is a floating-point type, then the two values are equal only if any of the following conditions is satisfied:
   • they are both +Inf.
   • they are both -Inf.
   • each of them is either -0.0 or +0.0.
   • they are both not NaN and they have the same bytes representations in memory.
4. If T is a complex type, then the two values are equal only if their real parts (as floating-point values) and imaginary parts (as floating-point values) are both equal.
5. If T is a pointer type (either safe or unsafe), then the two values are equal only if the memory addresses stored in them are equal.
6. If T is a channel type, the two channel values are equal if they both reference the same underlying internal channel structure value or they are both nil channels.
7. If T is a struct type, then each pair of the corresponding fields of the two struct values will be compared.
8. If T is an array type, then each pair of the corresponding elements of the two array values will be compared.
9. If T is an interface type, please read how two interface values are compared.
10. If T is a string type, please read how two string values are compared.

Please note, comparing two interfaces with the same incomparable dynamic type produces a panic. The following is an example in which some panics will occur in comparisons.

package main

func main() {
	type T struct {
		a interface{}
		b int
	}
	var x interface{} = []int{}
	var y = T{a: x}
	var z = [3]T{{a: y}}

	// Each of the following line can produce a panic.
	_ = x == x
	_ = y == y
	_ = z == z
}

• About Go 101 - why this book is written.
• Acknowledgments

• An Introduction of Go - why Go is worth learning.
• The Go Toolchain - how to compile and run Go programs.

• Become Familiar With Go Code
  • Introduction of Source Code Elements
  • Keywords and Identifiers
  • Basic Types and Their Value Literals
  • Constants and Variables - also introduces untyped values and type deductions.
  • Common Operators - also introduces more type deduction rules.
  • Function Declarations and Calls
  • Code Packages and Package Imports
  • Expressions, Statements and Simple Statements
  • Basic Control Flows
  • Goroutines, Deferred Function Calls and Panic/Recover

• Go Type System
  • Go Type System Overview - a must read to master Go programming.
  • Pointers
  • Structs
  • Value Parts - to gain a deeper understanding into Go values.
  • Arrays, Slices and Maps - first-class citizen container types.
  • Strings
  • Functions - function types and values, including variadic functions.
  • Channels - the Go way to do concurrency synchronizations.
  • Methods
  • Interfaces - value boxes used to do reflection and polymorphism.
  • Type Embedding - type extension in the Go way.
  • Type-Unsafe Pointers
  • Generics - use and read composite types
  • Reflections - the reflect standard package.

• Some Special Topics
  • Line Break Rules
  • More About Deferred Function Calls
  • Some Panic/Recover Use Cases
  • Explain Panic/Recover Mechanism in Detail - also explains exiting phases of function calls.
  • Code Blocks and Identifier Scopes
  • Expression Evaluation Orders
  • Value Copy Costs in Go
  • Bounds Check Elimination

• Concurrent Programming
  • Concurrency Synchronization Overview
  • Channel Use Cases
  • How to Gracefully Close Channels
  • Other Concurrency Synchronization Techniques - the sync standard package.
  • Atomic Operations - the sync/atomic standard package.
  • Memory Order Guarantees in Go
  • Common Concurrent Programming Mistakes

• Memory Related
  • Memory Blocks
  • Memory Layouts
  • Memory Leaking Scenarios

• Some Summaries
  • Some Simple Summaries
  • nil in Go
  • Value Conversion, Assignment and Comparison Rules
  • Syntax/Semantics Exceptions
  • Go FAQ 101

• More Go Related Topics