Cloning and Equality Checks

## The thing a slice variable holds A Go slice value is a small, fixed-size header made of three words: a **pointer** to the first element of a backing array, a **length** (how many elements this view exposes) and a **capacity** (how many array slots are available from that pointer onward). The elements themselves are *not* in the slice value. They live in an array somewhere else in memory, and the slice is a view onto it. Every assignment in Go copies the value on the right-hand side. For a slice that means the header is copied — pointer, length, capacity — and nothing else. So after ```go a := []int{1, 2, 3} b := a ``` there are two independent headers and exactly **one** array. `b` is not an alias of the variable `a`: reassigning `b = append(b, 4)` or `b = b[:1]` changes only `b`'s own header. But `b[0] = 9` reaches through the shared pointer and writes into the one array, so `a[0]` is now `9` as well. This is the single most common surprise for engineers arriving from a language where collections are objects with reference semantics, and it is also what makes passing a slice to a function cheap: you copy 24 bytes on a 64-bit machine, never the data. ## What slices.Clone does ```go b := slices.Clone(a) ``` `slices.Clone` allocates a **new backing array** with room for `len(a)` elements, copies the elements into it, and returns a header pointing at the new array. From that moment `a` and `b` have no storage in common, so `b[0] = 9` is invisible to `a` and `a[0] = 7` is invisible to `b`. The returned slice has the same length as the input; its capacity is at least that length and the documentation deliberately allows extra unused capacity, so do not write code that depends on `cap(slices.Clone(a)) == len(a)`. One special case worth memorising: **cloning a nil slice gives you a nil slice**, not an empty non-nil one. There is no array to allocate, so none is allocated. That matters downstream, because `reflect.DeepEqual` treats a nil slice and an empty slice as different and `encoding/json` writes `null` for the first and `[]` for the second. ## Shallow means shallow `slices.Clone` copies each element **using ordinary assignment** — exactly what `=` would do for that element type. For `[]int`, `[]string` or `[]time.Duration` that is a complete copy and the clone is fully independent. For anything whose value contains a pointer, it is not: - `[]*User` — the pointers are duplicated, the `User` structs behind them are shared. - `[][]byte` — each inner header is duplicated, each inner array is shared. - `[]map[string]string` — each map value is a pointer to one run-time hash table; both slices reach the same table, so a `delete` through the clone is visible through the original. - `[]struct{ Name string; Tags []string }` — the `Name` string data is immutable so it is effectively copied, but every `Tags` header is copied while its array stays shared. So `slices.Clone` gives you independence **at exactly one level**. If your element type owns a nested container and you need a genuinely independent copy, you must clone the nested containers yourself, element by element. The same rule applies to `maps.Clone`, which copies the key/value pairs by assignment: a `map[string][]string` clone shares every value slice. ## The related tools, and how they differ - `copy(dst, src)` is the builtin. You allocate `dst` yourself and it moves `min(len(dst), len(src))` elements. A `dst` you forgot to `make` with a length stays empty and `copy` silently reports 0 — a classic bug that `slices.Clone` removes by doing the allocation for you. - `append(s[:0:0], s...)` is the pre-generics idiom that `slices.Clone` replaced; the `:0:0` three-index slice forces `append` to allocate rather than write into the original's spare capacity. - `bytes.Clone` is the `[]byte`-specific equivalent, useful when you are handed a buffer whose owner will reuse it. None of these are deep copies. Go has no built-in deep copy, and that is a deliberate omission — a correct deep copy requires knowing what your types mean. ## Where this shows up in real code The pattern to internalise is: **a slice you return, store or hand to another goroutine is a promise about storage, not just about values.** If a method returns `s.items` directly, the caller can write through it and mutate your struct's state. If you hold a slice that came from a decoder or a pooled buffer, the owner may reuse that array under you. `slices.Clone` at the boundary is the cheap fix for both — provided the element type has no nested containers, in which case the clone is a comforting illusion rather than a defence. The reviewing question is always the same: after this copy, which memory is still shared, and who is allowed to write to it?