<p>I've not used a language with pointers before, and this part is throwing me. Say I have a struct type.</p>
<pre><code>type person struct {
name string
}
</code></pre>
<p>And a function that returns a new pointer to a struct of that type.</p>
<pre><code>func getSarah() *person {
sarah := &person{name: "Sarah Palmer"}
return sarah
}
</code></pre>
<p>I call <code>sarah := getSarah()</code>. <code>sarah</code> is now a pointer to a memory location containing a person struct.</p>
<p>But if I call <code>fmt.Println(sarah.name)</code>, that prints Sarah's name.</p>
<p>Why does this happen? <code>sarah</code> is a pointer, just a memory address. Why can I call <code>.name</code> on a memory address without dereferencing it to get at the actual data it points to?</p>
<hr/>**评论：**<br/><br/>fakeNAcsgoPlayer: <pre><p>x *T. (x is var of type pointer to T, where T can be anything ).</p>
<p>x.a and x->a are same in Go. No difference unlike C and C++. </p></pre>faiface: <pre><p>pointer.field is actually a syntactic sugar for (*pointer).field in Go. So it is dereferencing. This syntactic sugar exists to reduce typing.</p></pre>Bake_Jailey: <pre><p>I think the other comments are answering different questions than you're asking.</p>
<p>Go does not have something like <code>-></code> in C or C++ to access members of things you have pointers to, just <code>.</code>. You don't need to "dereference" anything, just access the struct's member through one simplified syntax.</p>
<p>See the language spec for selectors: <a href="https://golang.org/ref/spec#Selectors" rel="nofollow">https://golang.org/ref/spec#Selectors</a></p></pre>spiritofthetempest: <pre><p>There's a simple syntax rule that transforms . on a pointer to first dereference the pointer like -> would in C. The same thing happens when you pass a pointer to a method that expects a value. </p></pre>George3d6: <pre><p>A small mention here, when people say 'pointer' (and I believe in go this is the only meaning for pointer), they generally mean 'pointer to dynamically allocated memory'. </p>
<p>So, in that sense, every language that you probably used until now, languages like java, python or js basically 'force' you to use a pointer for everything, that is to say, all objects will be heap allocated and you will be working only with pointers to those (garbage collected) objects.</p></pre>deusmetallum: <pre><p>It's simply written to work that way, so you don't have to worry too much about what you're getting back from a function.</p></pre>9nut: <pre><p>because that's how fmt.Println is designed to work; that's to say it isn't inherent in the language, but a design decision in package fmt. look for the description of "%v" in:
<a href="https://golang.org/pkg/fmt/" rel="nofollow">https://golang.org/pkg/fmt/</a></p>
<p>the specific part starts with this paragraph: "<em>For compound objects, the elements are printed using these rules, recursively, laid out like this:</em>"</p></pre>
