> Go knows that doPerson can't modify person so it is free to allocate the variable on the stack Escape analysis does not care about modification. It only care

> Go knows that doPerson can't modify person so it is free to allocate the variable on the stack Escape analysis does not care about modification. It only cares about whether the scope of the variable may end up expanded past the end of the function. Whether that scope is read or write is not relevant. Causes of escape would be returning the value from the function, referencing the value in a closure, or using a reference to the value in a context with a different lifetime (channels, structs outliving the function). Calling a function with an argument as reference is not a cause of escape. Escape analysis is tricky and fragile. Go often has to bail out to the heap. Also, you don't really pass around structs by value much in real code, so the point that this is a benefit to GC performance is kind of moot.