Why does returning a Go struct by value still share its []float64 field between callers?

## What "copy the struct" actually copies Assignment, argument passing, returning, and a value receiver all copy a struct **field by field**, using each field's own copy semantics. Nothing about a struct copy is deep. Whether a copy is genuinely independent therefore depends entirely on what its fields are. Consider a measurement window a library hands to its callers: ``` type Window struct { Fixed [4]float64 Recent []float64 } ``` `Fixed` is an array. Its length is part of its type, and the value *is* its four float64s - 32 bytes. Copying the struct copies all four elements, so the copy is independent. `Recent` is a slice. Its value is a three-word header: a pointer to the first element in a backing array, a length, and a capacity. Copying the struct copies those three words. It does not, and cannot, copy the array behind the pointer - the compiler does not know how big it is at compile time and would not copy it if it did. Both structs now hold the same pointer. The result is a value that looks independent and behaves like a shared view for exactly one of its fields. ## The failure it produces The bug this causes is a copy that is not a copy. A caller receives a `Window` by value, edits `Recent[0]`, and a completely different caller - or the library's own internal state - sees the edit. Nothing in the type signature warns anyone. `Window` is returned by value, which every reader takes as a promise of isolation, and for `Fixed` it is one. The same trap applies to any pointer-bearing field: a `*T`, a map, a channel, or a struct that itself contains one of those. Slices are the case that surprises people most, because a slice looks like a container rather than a reference. ## Diagnosing it Two things settle it quickly. A debugger is the most direct. Stop on the return, expand both structs, and compare the slice fields: the length and capacity words may match innocently, but if the **data pointers** are equal, the two structs share elements and the "copy" is a fiction. This is one of the few bugs where a single glance at the raw header words is conclusive. Failing that, the behavioural test is trivial: take the copy, write a sentinel into the slice field, and read the original. If the sentinel is there, the field is shared. ## The library author's options **Use a fixed-size array field.** If the data really is a fixed number of measurements, `[16]float64` gives true value semantics: independent on copy, and comparable, so a struct built only from comparable fields can be tested with `==` and used as a map key. A struct containing a slice is not comparable at all - `==` on it is a compile error - which is a second, often-forgotten consequence of the same design. The cost is that every copy moves 128 bytes rather than 24, so this suits small, genuinely fixed shapes and not large ones. **Copy defensively at the boundary.** Return `slices.Clone(w.Recent)` (or clone the field before returning the struct) so each caller gets its own array. This costs an allocation per call, which is the honest price of isolation, and it is usually the right call for an exported API whose callers you do not control. **Copy on the way in as well.** A constructor that stores a caller-supplied slice is the mirror image of the same bug: the caller keeps a header into your internal array and can mutate your state afterwards. If the struct is meant to own its data, clone at the door. **Or document the sharing and mean it.** Sometimes sharing is the point - a view over a large buffer that you deliberately do not want to duplicate. That is a legitimate design, but it must be stated in the doc comment, because the type alone says the opposite. ## Why this decision is expensive to revisit An exported struct's field types are part of your API. Changing `Recent []float64` to `Fixed [16]float64`, or starting to clone on every return, changes both the compile-time shape and the observable aliasing behaviour for every team that imports the package. Callers may already, knowingly or not, depend on the sharing. That is why the question belongs at design time: decide whether the value you hand out is a snapshot or a window, encode it in the field type where you can, and say so in the documentation where you cannot.