Why mutation of a non-pointer receiver isn't a compiler error?

<p>Is it ever not a bug?</p> <p>If someone needs it, you can just make an explicit copy (which can be optimized away).</p> <hr/>**评论：**<br/><br/>Ainar-G: <pre><p>Maybe not a compiler error, but it should definitely be a <code>go vet</code> diagnostic. Especially if the copy is not used or returned afterwards.</p></pre>anossov: <pre><p>Ah yes, returning a modified copy makes sense.</p></pre>PsyWolf: <pre><p>Even if you aren&#39;t returning it, I can imagine a scenario where you want to make a modification to the copy and then pass the modified copy on to some other function.</p> <p>As long as you &#34;read the value&#34; in any way after setting it, it could be intentional. Now if you write to the copy and then never use it before leaving the function, that&#39;s almost certainly a bug that go vet could look for.</p></pre>hayzeus: <pre><p>I agree -- this should probably be in go vet (maybe not a compiler error, though).</p> <p>I&#39;d also like to see an option in go vet to check for totally ignored function returns (ie, without an underbar).</p></pre>weberc2: <pre><p>This should probably apply to all parameters, not just a receiver, right?</p></pre>hayzeus: <pre><p>Yeah -- you could be returning the modified copy though. Seems like a job for go vet as well</p></pre>weberc2: <pre><p>Right, but that&#39;s still true of any parameter, not just the receiver. Calling out the receiver in particular seems to imply that it deserves special treatment and I don&#39;t think that&#39;s true.</p></pre>hayzeus: <pre><p>Yes -- I&#39;m agreeing with you. I&#39;m only saying, that I&#39;d prefer this check to be in go vet, rather than the compiler.</p></pre>aboukirev: <pre><p>Non-pointer receiver is a copy. It is essentially passed by value (a copy) as first parameter to the method. </p></pre>tdewolff: <pre><p>He knows that. He wonders why the compiler doesn&#39;t provide a warning (error) when you modify the copy. Because in 90% of the times it is a bug that the receiver is a copy and you modify it (you thought it was a pointer receiver and wonder why the hell it doesn&#39;t work!).</p></pre>aboukirev: <pre><p>I specifically stated to think of it as a value parameter to the method. Do you want warnings for any modifications to value parameters? It might be logical to treat all value parameters in function as immutable. But that would be a different language altogether. </p> <p>One may want to alter something in the receiver and then pass it to another method or chain-call a method on a modified copy. That is a fully legitimate use case.</p></pre>wehavetobesmarter: <pre><p>I wouldn&#39;t even vet it to be fair. It&#39;s useful for immutable APIs. Go allows immutability by construction thanks to value types.</p></pre>lespritd: <pre><p>There are times I&#39;ve modified non-pointer receivers.</p> <p>To answer the question in the title, though, I think the reason is clear: go prizes implementation simplicity highly. It would make go, the implementation, more complicated to treat receivers and parameters differently.</p></pre>anacrolix: <pre><p>A good example of this is calling Lock on a sync.Mutex that&#39;s embedded in the copied receiver. It causes a race condition if you use any pointer value in the receiver that&#39;s supposed to be protected by that mutex.</p></pre>