<p>When there's an unused variable in the code, the compiler will complain. When there's an unused struct field, the compiler won't complain.
Why not?</p>
<p>My only explanation is because it may be just used by e.g. the json marshaller and may not be mentioned in the code.</p>
<hr/>**评论：**<br/><br/>nemith: <pre><p>The field could be in use by other packages. These packages could be future and not even in your GOPATH. </p>
<p>Even unexported fields are exposed via reflect. (don't do this).</p></pre>theo_retiker: <pre><p>So my explanation wasn't so wrong.
But I didn't thought about libraries, which makes totally sense to not remove unused fields. Thank you :)</p></pre>DualRearWheels: <pre><p>Padding?</p></pre>Morgahl: <pre><p>This. There are numerous places in the Go source that make use of struct padding for alignment reasons across 32 and 64 bit architectures. </p></pre>FuckinStopSayingThis: <pre></pre>Jelterminator: <pre><p>Well, they shouldn't because it's not in the spec: <a href="https://github.com/golang/go/issues/10014" rel="nofollow">https://github.com/golang/go/issues/10014</a></p></pre>tv64738: <pre><p>Because that's an situation that's much harder to detect, and its consequences are not a very common trap that would deserve explicitly protecting against.</p></pre>robe_and_wizard_hat: <pre><p>I think that's probably a really good theory as to why it doesn't get an error.</p></pre>allhatenocattle: <pre><p>Even if it isn't enforced by the compiler for the reasons below, you might still want to run an analysis tool like <a href="https://github.com/3rf/codecoroner" rel="nofollow">codecoroner</a> to find any dangling fields/functions that aren't used so they can be removed.</p></pre>theo_retiker: <pre><p>That seems to be a very useful tool. Thanks :D</p></pre>
