In Go, is it safe to return a pointer to a local variable from a function?

## The question behind the question Anyone arriving from C asks this first, because in C returning `&local` hands back a pointer into a frame that has already been popped, and using it is undefined behaviour. Anyone arriving from Java or Python asks the opposite question, because there every object is on the heap and there is nothing to worry about. Go sits between the two, and the answer is: write the code that reads best, and the compiler decides where the memory lives. ## Stack first, heap when it must Every Go function call gets a frame on the calling goroutine's stack. Local variables live there by default, which is the cheapest possible allocation — bumping a pointer, and no cleanup at all, because the whole frame disappears when the function returns. That only works while a value's lifetime is contained by the frame. If a reference to a local can still be reached after the function returns, the frame is the wrong place for it. The compiler detects this case during a pass called **escape analysis**: a value *escapes* when the compiler cannot prove its lifetime ends with the frame. Escaped values are allocated on the heap and are the garbage collector's responsibility. ## The canonical example ```go func newCounter() *int { n := 0 return &n } ``` The address of `n` is returned, so `n` outlives `newCounter`. Escape analysis notices, and `n` is heap-allocated. The frame holds a pointer to it. Callers get a perfectly valid `*int`. Build with `go build -gcflags=-m` and the compiler tells you so, printing `moved to heap: n`. Contrast: ```go func sum(a, b int) int { t := a + b return t } ``` Nothing takes the address of `t`, so `t` lives in a register or the frame and costs nothing. ## Why placement is not visible in the syntax The biggest misconception here is that some spelling forces the heap. It does not: - `new(T)` and `&T{}` are equivalent. Both produce a `*T`, and both are stack-allocated if the pointer does not escape. - Passing a pointer into a function does **not** force a heap allocation. If the callee only reads through the pointer and does not store it anywhere that outlives the call, the pointed-to variable stays in the caller's frame. Escape analysis records, per function, whether a pointer parameter is retained. - Not taking a pointer does not guarantee the stack either. A large local, or a `make` whose size is not a compile-time constant, is heap-allocated because the compiler cannot bound the frame. ## What escaping actually costs The program is correct either way — this is the point worth internalising. What changes is cost: a heap allocation is more expensive than a frame slot, and every heap object adds work for the garbage collector. In ordinary code that is irrelevant. In a function called millions of times a second it is exactly the thing you profile and then try to remove. That is also why the escape decision is not part of the language specification. It is a property of the current compiler, and it improves between releases. Code that relies on a value staying on the stack for *correctness* would be broken code; there is no such dependency in Go, because the semantics are identical either way. ## What typically makes a value escape At this level it is enough to recognise the shapes: - Its address is returned, as above. - Its address is stored somewhere longer-lived: a package-level variable, a field of an already-escaping struct, a slice or map that escapes. - It is captured by a function literal that itself escapes — stored in a slice, returned, or started as a goroutine. - It is passed to a function the compiler cannot see through, so the compiler must assume the worst. - It is too large, or its size is not known at compile time. ## How to check `go build -gcflags=-m ./...` prints one line per decision: `moved to heap: n` for a named variable whose address escapes, `&T{} escapes to heap` for an escaping composite literal, and `p does not escape` for a pointer parameter the callee does not retain. Adding a second `-m` (`-gcflags='-m -m'`) also prints the reasoning that led to each decision. ## Takeaway Return the pointer if the API wants a pointer. Go guarantees it is valid. Then, if and only if a benchmark says the allocation matters, go look at what the compiler decided and whether the API can be shaped to avoid it.