In Go programming, a nil slice behaves like a missing container, while an empty slice is a valid slice with zero length and underlying capacity. Understanding how an empty slice is created, stored, and used is essential for writing safe and efficient APIs.
Below is a structured overview that helps you quickly compare nil slices, empty slices, construction patterns, and zero-copy behavior in different scenarios.
| Slice State | Length | Capacity | Underlying Array |
|---|---|---|---|
| nil slice | 0 | 0 | none |
| empty slice via make | 0 | 0 or specified | present if capacity > 0 |
| empty slice via literal | 0 | 0 | none |
| empty after slicing | 0 | depends on source | shared with source |
Creating an Empty Slice Idiomatically
Using make with zero length
Use make([]T, 0) to create a typed empty slice with an underlying array when you may later grow the slice without reallocation overhead. This form is useful when the function returns a slice and you want to avoid nil semantics.
Using a slice literal
Declare an empty slice with []T{}. The literal produces a non-nil slice with zero length and zero capacity, which is safe to pass to functions that range over results and simplifies zero-value handling in JSON and protocol buffers.
Behavior and Memory Characteristics
Length, capacity, and nil checks
An empty slice returned by make([]T, 0) has length 0 and may have a positive capacity, allowing append without immediate allocation. Unlike a nil slice, it passes != nil checks, which can affect API contracts and JSON marshaling when the distinction matters.
Zero-copy slicing and shared storage
Slicing a non-empty slice to produce an empty slice preserves the underlying array reference. The new empty slice shares memory with the source, so mutating elements through the original slice can affect the empty slice if it is later extended. This behavior is useful for windowing patterns but requires care around ownership and lifetimes.
API Design and Nil Safety
Returning empty versus nil
Public functions that return slices should usually return an empty slice instead of nil to simplify client code. Callers can iterate safely with range, and reflection-based operations often behave more predictably. Reserve nil returns for error conditions or optional values where absence must be explicit.
Empty slices in struct fields
When a struct embeds a slice field, initializing it as an empty slice avoids nil pointer issues during iteration or marshaler processing. For public APIs, providing zero values in constructors or factory functions ensures consistent behavior across versions and reduces defensive allocations in user code.
Performance and Best Practices
Allocation patterns and growth
Creating an empty slice with a capacity hint using make([]T, 0, hint) reduces reallocations when the length grows later. Prefer append on empty slices over repeated concatenation to keep amortized complexity predictable and minimize memory fragmentation in long-running services.
Key Takeaways for Robust Slice Handling
- Prefer returning an empty slice from public functions to avoid nil-related panics.
- Use
make([]T, 0, hint)when you expect growth to reduce allocations and control capacity. - Remember that slicing a non-empty slice to an empty slice shares the underlying array.
- Choose between nil and empty based on semantic meaning, API clarity, and marshaling behavior.
- Initialize struct slice fields explicitly to ensure deterministic behavior across Go versions.
FAQ
Reader questions
Does an empty slice returned by make allocate memory immediately?
When you write make([]T, 0) without a capacity hint, Go typically allocates a zero-length backing array. Providing a second capacity argument, such as make([]T, 0, n) , allocates space for up to n elements upfront, which prevents reallocation as you append.
How does marshalling differ between nil and empty slices in JSON and protobuf?
JSON marshaling emits null for a nil slice and [] for an empty slice, while protobuf behavior depends on whether the field is repeated and whether language-specific options treat missing fields as unset. Being explicit about nil or empty return values avoids subtle changes in serialized payloads and API compatibility.
Can slicing a non-empty slice produce an empty slice that shares memory?
Yes, slicing with equal indices, such as s[i:i] , yields an empty slice that still references the same underlying array as the original. This is safe for read-only inspection, but mutating the original slice before extending the empty slice can lead to data races or unexpected overwrites if the empty slice is later appended to.
Should exported public APIs return nil or an empty slice when there are no elements?
Exported APIs should generally return an empty slice instead of nil to ensure safe ranging, simpler client logic, and consistent JSON marshaling. Return nil only when the distinction between absent and empty carries explicit semantic meaning for your domain or protocol contract.