The thing about slices

Slices are tricky. If you have been using Go for a while now, you may be aware that a slice is basically a triplet consisting of a:

  1. pointer to an array of values,
  2. the capacity of the array,
  3. the length of the array

This makes working with slices also a bit different than working with structs.

The slice operator

The first thing one should be aware of is that the slice operator, does not create a new slice. Not taking into account this fact, taking a look at the following example would produce unexpected results:

a := []string{"r","u","n"}
b := a[1:2]
b[0] = "a"
fmt.Println(a)

Does it print [r u n] or [r a n]? Since the slice b is not a copy of the slice, but just a slice with a modified pointer to the array, the above will print [r a n].

As explained, this is because the slice operator just provides an updated reference to the array from the original slice. From the official reference:

Slicing does not copy the slice’s data. It creates a new slice value that points to the original array. This makes slice operations as efficient as manipulating array indices. Therefore, modifying the elements (not the slice itself) of a re-slice modifies the elements of the original slice.

Source: Go Blog - Slices usage and internals.

Allocation by append

Appending to a slice is simple enough. As mentioned, the slice has a length which you can get with a call to len(), and a capacity which you can get with a call to cap().

a := []string{"r", "u", "n"}
fmt.Println(a, len(a), cap(a))
a = append(a, []string{"e"}...)
fmt.Println(a, len(a), cap(a))
a = a[1:len(a)]
fmt.Println(a, len(a), cap(a))

The expected output would be:

[r u n] 3 3
[r u n e] 4 4
[u n e] 3 3

Of course, that’s not how append works. Append will double the existing capacity. This means you’ll end up with output like this:

[r u n] 3 3
[r u n e] 4 6
[u n e] 3 5

If you wanted the previous result, you would have to create your own function, which would allocate only the required amount of items into a new slice, and then copy over the data from the source slice. This function could look something similar to this:

func suffix(source []string, vars ...string) []string {
	length := len(source) + len(vars)
	ret := make([]string, length, length)
	copy(ret, source)
	index := len(source)
	for k, v := range vars {
		ret[index+k] = v
	}
	return ret
}

func main() {
	a := []string{"r", "u", "n"}
	fmt.Println(a, len(a), cap(a))
	a = suffix(a, []string{"e"}...)
	fmt.Println(a, len(a), cap(a))
	a = a[1:len(a)]
	fmt.Println(a, len(a), cap(a))
}

Copying slices

As discovered above, “Slicing does not copy the slice’s data.”. This may sometimes have unintended consequences. This doesn’t apply only to slicing, but also passing slices into functions.

func flip(source []string) {
	source[1] = "a"
}

func main() {
	a := []string{"r", "u", "n"}
	flip(a)
	fmt.Println(a)
}

The above example will print [r a n]. This is unfortunate, because people intuitively expect slices to behave much like structs do. Passing a struct will create a copy. A slice will still point at the same memory that holds the data. Even if you pass a slice within a struct, you should be aware of this:

type X struct {
	c string
	source []string
}

func flip(x X) {
	x.c = "b"
	x.source[1] = "a"
}

func main() {
	a := X{"a", []string{"r", "u", "n"}}
	flip(a)
	fmt.Println(a)
}

The above will print out a {a [r a n]}. Slices always behave like they are passed by reference. In a way they are, as one of the parts of the slice is a pointer to the array of data it holds.

Using slices in channels

In case you’re using buffered channels, and are trying to be smart with slices - reusing a slice to keep allocations down, then you might find that this buffered channel is basically filled with the same slice over and over. As the slice contains the pointer to the array holding the data, the following example will have unexpected results:

func main() {
	c := make(chan []string, 5)

	go func() {
		item := []string{"hello"}
		for i := 0; i < 5; i++ {
			item[0] = fmt.Sprintf("hello %d", i)
			c <- item
			//time.Sleep(100 * time.Millisecond)
		}
	}()

	for i := 0; i < 5; i++ {
		item := <-c
		fmt.Println(item)
	}
}

The output is:

[hello 4]
[hello 4]
[hello 4]
[hello 4]
[hello 4]

If you uncomment the time.Sleep command in the goroutine, you will most likely get the correct result:

[hello 0]
[hello 1]
[hello 2]
[hello 3]
[hello 4]

At any time when the consumer is reading from the channel, the retrieved slice will be identical, because only the item in the underlying array is changing. The only solve for this I believe is either finding a way to work with an unbuffered channel (a consumer must always be waiting to read from the channel), or to explicitly copy the slice which is being put on the channel, like in this playground example.

Since you’re here… I started writing my third book, The SaaS Handbook. If you enjoy this blog, or if you would like to build your own SaaS/product, consider supporting me and buying a copy. Any income from the book is going towards writing new and insightful content and teaching people how to be better programmers. Thanks :)

About the author

I'm the author of API Foundations in Go and 12 Factor Apps with Docker and Go. You should read both books if you want to learn more about Docker and Go. I'm currently writing The SaaS Handbook which more broadly deals with the subject of setting up a SaaS or product business.

I'm available for consulting / development jobs. Fixing bottlenecks and scaling services to cope with high traffic is my thing. I specialize in back-end development with a focus on providing back-end APIs for consumption in Angular, React, Vue.js and other front-end technology stacks.