6

What is the point of differentiating between a nil slice, ie. uninitialized slice, and an empty slice, ie. initialized but empty slice?

I understand the difference, but I'm wondering what the motivation is behind having the subtle difference between the two cases? For all intents and purposes, a nil slice and an empty slice behave the same when using them.

It seems as though if Go developers just had one case, for example only allowed empty slices, it would have simplified the mental model and eliminated sources of subtle bugs.

Is there a reason why those two use cases were created?

icza
  • 389,944
  • 63
  • 907
  • 827
Ste
  • 183
  • 3
  • 8
  • 1
    Is this similar to https://stackoverflow.com/q/30806931/6309? – VonC Mar 05 '18 at 05:49
  • Which subtle bugs regarding nil slices are you referring too? – Volker Mar 05 '18 at 06:35
  • In some situations there is a subtle difference between "There are no apples in the box" and "There is no box". – Art Mar 05 '18 at 07:19
  • I've written an answer [here](https://stackoverflow.com/a/45997533/1561148), which has some explanation from the *"Go in action"* book that might shed some light... – tgogos Mar 05 '18 at 08:32

1 Answers1

6

A nil slice value needs no allocation. That might make a difference in cases where you want to build something in a slice, but often there will be no data to be appended, so the slice may remain nil, so no allocation will be required altogether.

An empty slice might require an allocation, even if its capacity is zero.

Also an empty slice means its length is 0, but its capacity may not be; so it's not true that "For all intents and purposes, a nil slice and an empty slice behave the same when using them.". You can allocate a slice with 0 length and a big capacity, optimizing for further appends to avoid allocations (and copying over):

s := make([]int, 0)
fmt.Println(s, len(s), cap(s))
s = append(s, 1)
fmt.Println(s, len(s), cap(s))

s = make([]int, 0, 10)
fmt.Println(s, len(s), cap(s))
s = append(s, 1)
fmt.Println(s, len(s), cap(s))

Output of the above (try it on the Go Playground):

[] 0 0
[1] 1 2
[] 0 10
[1] 1 10

What do we see? In the first example we created an empty slice with 0 length and 0 capacity. If we append an element to it, its length will become 1 (obviously), and its capacity increased to 2. This is because under the hood append() allocated a new array with size of 2 (thinking of future growth), copied the existing elements over (which was none in this case), and assigned the new element.

In the second case we started with an empty slice but with a capacity of 10. This means we can append 10 elements to it without causing a new allocation and copying existing elements. This can be a big plus when slices are big and this needs to be done many times.

icza
  • 389,944
  • 63
  • 907
  • 827
  • 1
    I think this is in general a good explanation of the behaviour of slices, but does not answer the question of _why_ there is a difference. In the code example above you could easily replace the first line with `var s []int` (creating a nil slice) and the outputs would be the same. Thus it is a fair question why the language designers decided it was necessary to differentiate here. It would have been possible to implement slices with a capacity of 0 as allocation-free, but a difference was made. It would be interesting to understand the rationale behind that. – NobodysNightmare Jun 24 '22 at 05:53
  • @NobodysNightmare The difference is that appending to a `nil` or 0-length slice needs allocation. Appending to a non-`nil` slice with sufficient capacity does not need allocation, it's enough to reslice the slice. This is in the answer. – icza Jun 24 '22 at 06:04
  • Yes, but this was not the question. The question was about the difference between a nil slice and an empty (also capacity 0) slice, not between two kinds of empty slices. I can totally see that having a non-zero capacity is advantageous. I came across this after having a failed test that expected a nil slice (actual) to be equal to an empty slice, which it was not according to the testing framework. That's one kind of subtle problem one may encounter due to this. – NobodysNightmare Jun 24 '22 at 13:39