I assume its because they don't want references everywhere. For example, allowing the programmer to choose if an object is allocated on the stack or heap, passed by reference (using a pointer) or by value.
Now, I don't see it written there that it is on the stack, but I imagine so. From the source code of 6g, in cgen.c[2], line 884, you can see this comment:
/*
* n is on stack, either local variable
* or return value from function call.
* return n's offset from SP.
*/
Sounds to me that local variables and return values are always on the stack, which makes sense to me.
I cant, since I'm not terribly familiar with Go. Like I said, I assume that this is the reasoning behind supporting pointers, rather than references to everything. I did not actually check.
C-style stack allocated objects captured by closures are not memory-safe in the absence of escape analysis. If the closure outlives the stack frame that allocated the object, a dangling pointer may occur, unless the stack frame itself is allocated on the heap, or the captured objects are moved by the compiler into a structure which is itself allocated on the heap.
