Does anyone have a good reference for Go pass-by reference, pass-by value, and pass-by pointer?

<p>Talking about pointers, and pointer pointers today.. Wondering if anyone has any good literature on the topic?</p> <p>Cheers</p> <hr/>**评论：**<br/><br/>lstokeworth: <pre><p>Go has pass by value only. I think you want to learn about pointers.</p></pre>jamesrr39: <pre><p>I wrote up something as a learning exercise when I was starting out with Go, having only used languages which choose what you&#39;ll pass for you before. This might come in handy: <a href="https://gist.github.com/jamesrr39/84b6d6c65c3d16a6aa47" rel="nofollow">https://gist.github.com/jamesrr39/84b6d6c65c3d16a6aa47</a></p></pre>from_cork: <pre><p>Go is pass by value, meaning that the value passed to the function is copied. When you pass a pointer to a function, the pointer is copied but it still references the same original value. </p> <p>I worked this up to show you some use cases. Feel free to ask any questions if you have them.</p> <p><a href="https://play.golang.org/p/a-IXqPhNxw">https://play.golang.org/p/a-IXqPhNxw</a></p></pre>itsamemmario: <pre><p>One thing that is interesting to note (in comparison to C) is that a pointer to a value created in a function can be returned by the function. Go takes care of moving it from the stack to the heap. Not sure if you want to go into that much technical detail, but it&#39;s pretty cool. from the docs: Note that, unlike in C, it&#39;s perfectly OK to return the address of a local variable; the storage associated with the variable survives after the function returns. In fact, taking the address of a composite literal allocates a fresh instance each time it is evaluated, so we can combine these last two lines.</p> <p><a href="https://golang.org/doc/effective_go.html#composite_literals" rel="nofollow">https://golang.org/doc/effective_go.html#composite_literals</a></p></pre>XANi_: <pre><p>Isn&#39;t that the case with any language with builtin GC ?</p></pre>14Niggerkiller88: <pre><p>Everything is passed by value.</p> <p>You (usually) use a pointer for structs.</p> <p>And never a pointer to an interface.</p></pre>dragonfax: <pre><p>This is a little tricky. Made trickier by the fact that Golang isn&#39;t consistent across its data types.</p> <p>Slices are passed by value, but they seem passed by reference, because the content of the slice isn&#39;t passed in that &#34;value&#34; only the &#34;header&#34; is.</p> <p>But then to make it worse, you still need to pass a pointer to a slice, if you plan on appending to the slice, as that modifies the value that was passed, as that change wont&#39; be communicated back up to the caller.</p> <p>But maps have no such issue, and always passing its value (which is also a reference of sorts) is just fine. Interfaces are similar. Passing the value is okay because that value itself won&#39;t change, and is small.</p> <p>Then there is pointer and non-pointer receivers. Which has nothing to do with whether your passing pointers of the object to other functions or not, only to its own methods.</p> <p><strong>Rules</strong></p> <p>I have a few general rules I follow first, and then wait until later, or until the situation calls for it, before I think to deeply about how to pass any data into a function as an argument.</p> <ol> <li>If it could be changed by the callee, and its one of those reference datatypes, then pass the value anyways.</li> <li>If it could be changes by the callee, and its not one of those references types, pass a pointer to it.</li> <li>If its small (a few bytes), pass the value,</li> <li>If its not smal, and its not a reference datatype, pass a pointer to it</li> </ol> <p>But #4 has an addendum to it. I tend to choose a single &#34;owner&#34; for any large piece of data. It might a function that owns it, or a another struct that contains it. And that owner will have the data as a &#34;value&#34; and never a &#34;pointer&#34;. Then when it passes that data around to other things, it passes a pointer to the data. </p> <p>This means there is no data in the application that is referenced only by pointers. Someone somewhere has the value itself. I.E its on someones stack somewhere, and not in the HEAP. For functions this means it can be tracked up to some function-call high up in the call chain thats long lived.</p> <p>This is less important in Golang with its escape analysis and good GC. But its still a good rule.</p></pre>dmikalova: <pre><p>FYI what you say about slices is misleading. A slice in it&#39;s totality is a pointer to an array, the length of the slice, and the capacity of the slice. Go is always pass by value, and so when a slice is passed the entirety of the slice is copied - which ends up only being a pointer and 2 ints. Compare to passing an array - the entire array will also be copied, but unlike a slice an array holds all the data itself. Likewise you could also pass a pointer to a slice or a pointer to an array, and that will also be passed by value - in these cases just a pointer is copied.</p></pre>