nil slices vs non-nil slices vs empty slices in Go language

Observable behavior

nil and empty slices (with 0 capacity) are not the same, but their observable behavior is the same (almost all the time). By this I mean:

• You can pass them to the builtin len() and cap() functions
• You can for range over them (will be 0 iterations)
• You can slice them (by not violating the restrictions outlined at Spec: Slice expressions; so the result will also be an empty slice)
• Since their length is 0, you can’t change their content (appending a value creates a new slice value)

See this simple example (a nil slice and 2 non-nil empty slices):

var s1 []int         // nil slice
s2 := []int{}        // non-nil, empty slice
s3 := make([]int, 0) // non-nil, empty slice

fmt.Println("s1", len(s1), cap(s1), s1 == nil, s1[:], s1[:] == nil)
fmt.Println("s2", len(s2), cap(s2), s2 == nil, s2[:], s2[:] == nil)
fmt.Println("s3", len(s3), cap(s3), s3 == nil, s3[:], s3[:] == nil)

for range s1 {}
for range s2 {}
for range s3 {}

Output (try it on the Go Playground):

s1 0 0 true [] true
s2 0 0 false [] false
s3 0 0 false [] false

(Note that slicing a nil slice results in a nil slice, slicing a non-nil slice results in a non-nil slice.)

Besides an exception, you can only tell the difference by comparing the slice value to the predeclared identifier nil, they behave the same in every other aspect. Do note however that many packages do compare slices to nil and may act differently based on that (e.g. encoding/json and fmt packages).

The only difference is by converting the slice to an array pointer (which was added to the language in Go 1.17). Converting a non-nil slice to an array pointer will result in a non-nil pointer, converting a nil slice to an array pointer will result in a nil pointer.

To tell if a slice is empty, simply compare its length to 0: len(s) == 0. It doesn’t matter if it’s the nil slice or a non-nil slice, it also doesn’t matter if it has a positive capacity; if it has no elements, it’s empty.

s := make([]int, 0, 100)
fmt.Println("Empty:", len(s) == 0, ", but capacity:", cap(s))

Prints (try it on the Go Playground):

Empty: true , but capacity: 100

Under the hood

A slice value is represented by a struct defined in reflect.SliceHeader:

type SliceHeader struct {
    Data uintptr
    Len  int
    Cap  int
}

In case of a nil slice, this struct will have its zero value which is all its fields will be their zero value, that is: 0.

Having a non-nil slice with both capacity and length equal to 0, Len and Cap fields will most certainly be 0, but the Data pointer may not be. It will not be, that is what differentiates it from the nil slice. It will point to a zero-sized underlying array.

Note that the Go spec allows for values of different types having 0 size to have the same memory address. Spec: System considerations: Size and alignment guarantees:

A struct or array type has size zero if it contains no fields (or elements, respectively) that have a size greater than zero. Two distinct zero-size variables may have the same address in memory.

Let’s check this. For this we call the help of the unsafe package, and “obtain” the reflect.SliceHeader struct “view” of our slice values:

var s1 []int
s2 := []int{}
s3 := make([]int, 0)

fmt.Printf("s1 (addr: %p): %+8v\n",
    &s1, *(*reflect.SliceHeader)(unsafe.Pointer(&s1)))
fmt.Printf("s2 (addr: %p): %+8v\n",
    &s2, *(*reflect.SliceHeader)(unsafe.Pointer(&s2)))
fmt.Printf("s3 (addr: %p): %+8v\n",
    &s3, *(*reflect.SliceHeader)(unsafe.Pointer(&s3)))

Output (try it on the Go Playground):

s1 (addr: 0x1040a130): {Data:       0 Len:       0 Cap:       0}
s2 (addr: 0x1040a140): {Data: 1535812 Len:       0 Cap:       0}
s3 (addr: 0x1040a150): {Data: 1535812 Len:       0 Cap:       0}

What do we see?

• All slices (slice headers) have different memory addresses
• The nil slice has 0 data pointer
• s2 and s3 slices do have the same data pointer, sharing / pointing to the same 0-sized memory value