Why does Go allow unused in some cases?

<p>Why does Golang allow unused globals in package main?</p> <p>And why does it allow unused unexported functions?</p> <p>Or unused fields?</p> <hr/>**评论：**<br/><br/>kjk: <pre><p>Because it&#39;s rather expensive to prove that global variables, functions or struct fields are unused. Making those checks would make compilation slow.</p> <p>There are checkers for that: <a href="https://github.com/alecthomas/gometalinter">https://github.com/alecthomas/gometalinter</a></p></pre>xiegeo: <pre><p>That is really cool! Is there a way to use gometalinter on changed code only? Or diff the linter&#39;s out put on current work space with last commit as a sort of automatic code review?</p></pre>semi-: <pre><p>As far as I know, no. It&#39;s something I&#39;ve been toying with the idea of, because currently gometalinter just produces so much output it&#39;s hard for me to tell if I&#39;m improving things or making them worse.</p> <p>The ideal fix would be some kind of AST-based diffing to only process packages that are syntactically different, but that would also be the hardest way to do it.</p> <p>The easiest way I can think of would be to just break the output up in to a directory structure based on package names and maybe linter name, then when you&#39;re done linting your entire project you could diff your output to the last output and only show that. I&#39;m not sure if I&#39;ll end up going through with that or not though, I&#39;ve spent more time than I&#39;d like just getting gometalinter and gitlab-ci playing nicely together, so I don&#39;t want to spend too much more time on it right now.</p></pre>rr1pp3rr: <pre><p>You may be using the method through reflection. You may be creating a global variable to be used by another package.</p> <p>Local unused variable never really make sense.</p></pre>dominikh: <pre><blockquote> <p>You may be using the method through reflection</p> </blockquote> <p>You cannot use reflection to call unexported package-level functions.</p> <blockquote> <p>You may be creating a global variable to be used by another package</p> </blockquote> <p>You cannot import package main.</p></pre>titpetric: <pre><p>You can use go build to compile files selectively from the main package namespace. For example, encode.go and decode.go which would be CLI programs, but wouldn&#39;t need each-other.</p> <p>Also, you can have test-specific code in package main which is used by tests only. Obviously you&#39;re not compiling tests along with the application. It&#39;s also a valid scenario for package-level functions, at least the <code>gvt</code> package manager removes test files from vendor/ when it pulls dependencies.</p> <p>Personally, it&#39;s a bit of a crutch in the sense you can leave dead code around and collect some tech debt. But as I usually package my logic, I&#39;m not very much exposed to this.</p></pre>xiegeo: <pre><p>So you can build the parts first.</p></pre>sh41: <pre><p>I believe there was an elegant answer by Ian Lance Taylor somewhere, but I can&#39;t find it now... :(</p></pre>