Why does Go allow unused in some cases?

Why does Golang allow unused globals in package main?

And why does it allow unused unexported functions?

Or unused fields?

Because it's rather expensive to prove that global variables, functions or struct fields are unused. Making those checks would make compilation slow.

There are checkers for that: https://github.com/alecthomas/gometalinter

That is really cool! Is there a way to use gometalinter on changed code only? Or diff the linter's out put on current work space with last commit as a sort of automatic code review?

As far as I know, no.  It's something I've been toying with the idea of, because currently gometalinter just produces so much output it's hard for me to tell if I'm improving things or making them worse.

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.

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're done linting your entire project you could diff your output to the last output and only show that.  I'm not sure if I'll end up going through with that or not though, I've spent more time than I'd like just getting gometalinter and gitlab-ci playing nicely together, so I don't want to spend too much more time on it right now.

You may be using the method through reflection. You may be creating a global variable to be used by another package.

Local unused variable never really make sense.

You may be using the method through reflection

You cannot use reflection to call unexported package-level functions.


You may be creating a global variable to be used by another package

You cannot import package main.

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't need each-other.

Also, you can have test-specific code in package main which is used by tests only. Obviously you're not compiling tests along with the application. It's also a valid scenario for package-level functions, at least the gvt package manager removes test files from vendor/ when it pulls dependencies.

Personally, it'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'm not very much exposed to this.

So you can build the parts first.

I believe there was an elegant answer by Ian Lance Taylor somewhere, but I can't find it now... :(