3 ms·

(I've never used Go, so please correct any errors.) > var _ = unusedImport This is what the devs suggest as an alternative to having a compiler flag to turn o

by philh 10y ago

(I've never used Go, so please correct any errors.) > var _ = unusedImport This is what the devs suggest as an alternative to having a compiler flag to turn off the check. But with a compiler flag, I can easily discover the unused import when I build for production, simply by turning that flag off. By using the variable in a dummy way, I need to remember to go back and check for such things. Presenting this as a way to address the problem feels like it's missing the point.

themihai 10y ago
In practice you don't really have this problem. It's a beginners issue thst's not worth "fixing" because there are tools that can help(goimports). I'm glad there are not such compiler flags.
- hueving 10y ago
  Goimports doesn't help when the name is ambiguous. >I'm glad there are not such compiler flags. Because if they were there people would force you to use them? Or are you just unhappy that people could have a different debugging workflow than you?
  - themihai 10y ago
    > Goimports doesn't help when the name is ambiguous. You can fork it and set it to only remove unused imports. In fact I've done just that few days ago but for different reasons(i.e. I generate some small programs and I use goimports as a quick and dirty way to to clean-up the unused imports). Here is the line where you need to return https://github.com/golang/tools/blob/master/imports/fix.go#L153 https://github.com/golang/tools/blob/master/imports/fix.go#L... > Because if they were there people would force you to use them? Or are you just unhappy that people could have a different debugging workflow than you? Yeah, I don't want being forced to use a dozen of flags just to compile a hello world program. Nor I do what to see various warnings that nobody really care about. It should fail or succeed. I prefer basic/minimal API that I can build upon not a kitchen sink approach. I think that's what makes Go a great ecosystem compared with many others. Compare the current Go compiler with various C++ compilers and you understand what I mean. To sum it up you may use separate tools to do various magic things (i.e. goimports), they do not need to obey the Go1 compatibility rules. The issue is not that big to warrant a compiler flag.
    - philh 10y ago
      > You can fork it and set it to RemoveOnly. This seems like it removes half the value of the tool, though. I can comment out a line of code, compile and test the program. But if I uncomment that line, I'm now missing an import. edit- how does a tool like this sound? * If it sees an unused import, it comments it out * If it sees an import is needed, and there's a commented-out import which would fit, it uncomments it. * It can run in a "check for commented-out imports" mode, so that commit hooks can reject such a state. I guess (making some assumptions about go's import semantics) this would avoid the ambiguous name problem; it would mean you avoid having to edit both the import and the usage at the same time; and it makes it easy to tell if a file should be cleaned up. Maybe it would cause issues if you're trying to choose between two libraries which both provide the same symbols?
      - themihai 10y ago
        Well, that's the point! If you don't want inaccurate imports and just want to remove unused imports you can comment that line. A better option would be to use an additional argument to that function (removeOnly bool) and perhaps a flag on the executable so that you can choose when to use the removeOnly option. Either way the automatic imports and even the removeOnly option alone requires various trade-offs(i.e. accuracy, compiler speed etc) and this is another reason why such features are better developed in stand alone/external tools.

by philh 10y ago

themihai 10y ago

In practice you don't really have this problem. It's a beginners issue thst's not worth "fixing" because there are tools that can help(goimports). I'm glad there are not such compiler flags.

hueving 10y ago
Goimports doesn't help when the name is ambiguous. >I'm glad there are not such compiler flags. Because if they were there people would force you to use them? Or are you just unhappy that people could have a different debugging workflow than you?
- themihai 10y ago
  > Goimports doesn't help when the name is ambiguous. You can fork it and set it to only remove unused imports. In fact I've done just that few days ago but for different reasons(i.e. I generate some small programs and I use goimports as a quick and dirty way to to clean-up the unused imports). Here is the line where you need to return https://github.com/golang/tools/blob/master/imports/fix.go#L153 https://github.com/golang/tools/blob/master/imports/fix.go#L... > Because if they were there people would force you to use them? Or are you just unhappy that people could have a different debugging workflow than you? Yeah, I don't want being forced to use a dozen of flags just to compile a hello world program. Nor I do what to see various warnings that nobody really care about. It should fail or succeed. I prefer basic/minimal API that I can build upon not a kitchen sink approach. I think that's what makes Go a great ecosystem compared with many others. Compare the current Go compiler with various C++ compilers and you understand what I mean. To sum it up you may use separate tools to do various magic things (i.e. goimports), they do not need to obey the Go1 compatibility rules. The issue is not that big to warrant a compiler flag.
  - philh 10y ago
    > You can fork it and set it to RemoveOnly. This seems like it removes half the value of the tool, though. I can comment out a line of code, compile and test the program. But if I uncomment that line, I'm now missing an import. edit- how does a tool like this sound? * If it sees an unused import, it comments it out * If it sees an import is needed, and there's a commented-out import which would fit, it uncomments it. * It can run in a "check for commented-out imports" mode, so that commit hooks can reject such a state. I guess (making some assumptions about go's import semantics) this would avoid the ambiguous name problem; it would mean you avoid having to edit both the import and the usage at the same time; and it makes it easy to tell if a file should be cleaned up. Maybe it would cause issues if you're trying to choose between two libraries which both provide the same symbols?
    - themihai 10y ago
      Well, that's the point! If you don't want inaccurate imports and just want to remove unused imports you can comment that line. A better option would be to use an additional argument to that function (removeOnly bool) and perhaps a flag on the executable so that you can choose when to use the removeOnly option. Either way the automatic imports and even the removeOnly option alone requires various trade-offs(i.e. accuracy, compiler speed etc) and this is another reason why such features are better developed in stand alone/external tools.