3 ms·

What's the argument for allowing un-used imports? I've never run into a case where I wished I had imported something but didn't want to use it If you're lookin

What's the argument for allowing un-used imports? I've never run into a case where I wished I had imported something but didn't want to use it If you're looking at future code, you can accomplish that by commenting out the import. But I've never run into the situation where writing future code has been good, or where I wouldn't have remembered to import the package I needed when I wrote that code. If you really need to import packages you're not using, and for some reason can't spend the time to comment those out, GO probably isn't for you. I just haven't heard of a case where doing otherwise would have been helpful.

zzzcpan 13y ago
I don't know how people write their code, but I don't like thinking about satisfying compiler when I'm working on some idea, it takes some of my thinking power. I'd rather do that later, probably together with unit tests.
jlarocco 13y ago
I think this is a matter of the way an individual person writes code, and not something that can be generalized by saying "this is never useful" or "this is always useful". Some people will find it annoying, others not. I personally find it annoying because I compile often. In my workflow I write code for a few minutes then compile it and run some quick tests or even run it through the debugger to make sure everything is working the way I expect. If everything checks out I start on the next bit. I may be adding a feature that I know in advance will use libraries xxx, yyy, and zzz. The natural thing to do is to add those imports when I open the source files that will use them, then get to work implementing the feature. Another useful reason is to import a library just to make sure it's installed correctly, before writing the code that uses it, although that's less common.
deleted 13y ago
[deleted]
ridiculous_fish 13y ago
Say you're trying to debug something, and you add a call to fmt.Printf. 'Compile error, "Undefined: fmt."' No problem, add 'import "fmt"' at the top. Now it's debugged, so let's remove the annoying logging statement. Oops: 'Compile error: "imported and not used: fmt."' So now you remove the import, knowing full well you're going to be adding it back again in a minute or two. Annoying! Or maybe, as part of debugging, you temporarily comment out a block of code. You just made a bunch of variables and imports unused, and you can't even test your changes until you clean them up. Exploratory programming and debugging puts code in transiently dirty states, and Go's enforced hygiene is onerous in those cases.

zzzcpan 13y ago

I don't know how people write their code, but I don't like thinking about satisfying compiler when I'm working on some idea, it takes some of my thinking power. I'd rather do that later, probably together with unit tests.

jlarocco 13y ago

I think this is a matter of the way an individual person writes code, and not something that can be generalized by saying "this is never useful" or "this is always useful". Some people will find it annoying, others not. I personally find it annoying because I compile often. In my workflow I write code for a few minutes then compile it and run some quick tests or even run it through the debugger to make sure everything is working the way I expect. If everything checks out I start on the next bit. I may be adding a feature that I know in advance will use libraries xxx, yyy, and zzz. The natural thing to do is to add those imports when I open the source files that will use them, then get to work implementing the feature. Another useful reason is to import a library just to make sure it's installed correctly, before writing the code that uses it, although that's less common.

deleted 13y ago

[deleted]

ridiculous_fish 13y ago

Say you're trying to debug something, and you add a call to fmt.Printf. 'Compile error, "Undefined: fmt."' No problem, add 'import "fmt"' at the top. Now it's debugged, so let's remove the annoying logging statement. Oops: 'Compile error: "imported and not used: fmt."' So now you remove the import, knowing full well you're going to be adding it back again in a minute or two. Annoying! Or maybe, as part of debugging, you temporarily comment out a block of code. You just made a bunch of variables and imports unused, and you can't even test your changes until you clean them up. Exploratory programming and debugging puts code in transiently dirty states, and Go's enforced hygiene is onerous in those cases.