title: Go FAQ's explanation of method sets
body: <blockquote>
  <p>Even in cases where the compiler could take the address  of a value to pass to the method, if the method modifies  the value the changes will be lost in the caller.  As an example, if the Write method of bytes.Buffer used a value receiver rather than a pointer, this code:</p>
  <pre class="lang-golang prettyprint-override"><code>var buf bytes.Buffer
  io.Copy(buf, os.Stdin)
  </code></pre>
  <p>would copy standard input into a copy of buf, not into buf itself. This is almost never the desired behavior.</p>
  </blockquote>
  <p>This is a quote from <a href="https://golang.org/doc/faq#different_method_sets" rel="nofollow noreferrer">Go FAQ</a>.</p>
  <p>I get it that the method set of <code>*T</code> is a superset to the one for <code>T</code>, but the paragraph above doesn't make sense to me anyway.</p>
  <p>My understanding is that for <code>T</code> we have no guarantees that it is addressable so in the general case the implicit <code>&amp;T</code> (available in methods for non-interface values) might not be valid.</p>
  <p>In the example above, there is a local variable <code>buf</code> which is addressable by definition so what is wrong with passing <code>&amp;buf</code> (explicit or implicit) to the method?
  Passed this way, it's possible to mutate the original <code>buf</code> (just as with all methods with receiver types and implicit <code>T-&gt;&amp;T</code> conversion), but it seems that I am missing something in that example.</p>