First, a general point. We care very much about getting the default experience right for Go users. These features are opt-in because we believe in both cases that "on" is the right default, that developers will be more productive with these on by default than having to know to opt in.
- You should also not have to ask for "go test" to point out certainly erroneous code instead of forcing you to find that code by debugging a test failure. - You should not have to ask for "go test ./...; modify a few source files; go test ./..." to do the right thing and only rerun the test binaries affected by your changes. A new Go programmer who doesn't know these features exist should get the benefit of these from day 1, without having to learn to set extra configuration (which doesn't actually exist) or type extra arguments on every go test command. Of course, turning them on by default means they have to be right, and we're very sensitive to that. If you find concrete examples where automatic vet or automatic test caching is causing you pain, please file issues so that we can look to see if the defaults need further adjustment. But please give them a chance first, actually try them, and then report concrete problems, not hypotheticals based on simply reading the release notes. Now a few specifics. For test caching: > Or maybe you are trying to debug a flaky test (up-enter enough times to get the intermittent error back now requires a -count=1). Two things about this. First, you only have to type -count=1 once, since the next up-enter will get it. But second, you may not have to type it all. If the command you are running is "go test", with an implicit "test the current directory", then there is no caching. See the description of "local directory mode" in http://beta.golang.org/cmd/go/#hdr-Test_packages. For vet during test: > why just go vet? Because vet is about correctness, and so is testing. If you are running "go test", you are in effect saying "check for bugs in this package". If those bugs can be reported directly - this line has this specific problem - instead of indirectly as test failures, that seems like a win. > Why a subset of its checks? Because vet has historically been opt-in, not all of the checks are appropriate to make opt-out. In particular, we won't enable a check during 'go test' unless it is accurate essentially 100% of the time, and if that "essentially 100%" is not exactly 100%, there has to be a very clear workaround. The idea is that vet sits quietly and you don't know it's running until it speaks up with something important, something you actually are happy to find out about and fix without debugging a test. If we are falling short of that with a specific check, please file an issue with concrete details. > Why not golint? Because golint is not about correctness. Golint is mostly about what your code *looks* like, not what it means. The things it points out aren't nearly important enough to block running a test. > why are they not compiler errors? There's a balance to strike here, again to make sure that opt-out is reasonable. The code is valid Go code, as you say, so it probably should continue to compile, especially if it's just someone else's dependency. Maybe that code path never runs in the program being compiled. On the other hand, when you are running "go test" of a specific package, you're asking "check for bugs in this package", so that seems like exactly the right time to subject that package's code (and only that package) to additional correctness checks and report any problems. Once again, please give these a chance, try them, and report problems on the issue tracker, with concrete details. That's how we'll make sure these are ready to be on by default. Thanks for your help testing Go 1.10. Best, Russ -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
