3 ms·

My experience with GoLand is that it manages to add back the right imports (notably with things like errors vs github.com/pkg/errors vs github.com/cockroachdb/e

My experience with GoLand is that it manages to add back the right imports (notably with things like errors vs github.com/pkg/errors vs github.com/cockroachdb/errors, where they all share a package name and ~interface) but that might just be me getting lucky or not noticing changes.

kstenerud 7y ago
You got lucky. And it still doesn't solve the problem of unused variables. At the end of the day, it's a hair shirt. And no matter how many coping mechanisms people come up with, it's still a hair shirt. Even the go authors had to put a limit on their madness. You'll notice that unused unexported functions don't cause compilation errors despite the fact that they, too, fall afoul of the original justification for this policy: https://golang.org/doc/faq#unused_variables_and_imports https://golang.org/doc/faq#unused_variables_and_imports "The presence of an unused variable may indicate a bug, while unused imports just slow down compilation, an effect that can become substantial as a program accumulates code and programmers over time. For these reasons, Go refuses to compile programs with unused variables or imports, trading short-term convenience for long-term build speed and program clarity." But disallowing unused functions would have been a bridge too far, so we're left with this half-measure and half-reasoning that doesn't even make sense.
- omegabravo 7y ago
  > But disallowing unused functions would have been a bridge too far, so we're left with this half-measure and half-reasoning that doesn't even make sense. how would you find an unused function?
  - kstenerud 7y ago
    The same way you detect unused variables: Look for accesses, and if nothing accesses the function, it's unused. Note that I'm talking about non-exported functions (i.e. someFunction rather than SomeFunction).
- sethammons 7y ago
  while a pain, for unused variables, if it comes up, right under the declared variable, just add the line: _ = myVar. Bingo, now it is used. Gross, but works.

kstenerud 7y ago

You got lucky. And it still doesn't solve the problem of unused variables. At the end of the day, it's a hair shirt. And no matter how many coping mechanisms people come up with, it's still a hair shirt. Even the go authors had to put a limit on their madness. You'll notice that unused unexported functions don't cause compilation errors despite the fact that they, too, fall afoul of the original justification for this policy: https://golang.org/doc/faq#unused_variables_and_imports https://golang.org/doc/faq#unused_variables_and_imports "The presence of an unused variable may indicate a bug, while unused imports just slow down compilation, an effect that can become substantial as a program accumulates code and programmers over time. For these reasons, Go refuses to compile programs with unused variables or imports, trading short-term convenience for long-term build speed and program clarity." But disallowing unused functions would have been a bridge too far, so we're left with this half-measure and half-reasoning that doesn't even make sense.

omegabravo 7y ago
> But disallowing unused functions would have been a bridge too far, so we're left with this half-measure and half-reasoning that doesn't even make sense. how would you find an unused function?
- kstenerud 7y ago
  The same way you detect unused variables: Look for accesses, and if nothing accesses the function, it's unused. Note that I'm talking about non-exported functions (i.e. someFunction rather than SomeFunction).
sethammons 7y ago
while a pain, for unused variables, if it comes up, right under the declared variable, just add the line: _ = myVar. Bingo, now it is used. Gross, but works.