On 15 February 2017 at 13:48, <howardcs...@gmail.com> wrote: >> >> > Side-note: I don't think goimports can actually do what you are saying, >> > can it? Because, if you run goimports on a valid program, it won't actually >> > *change* any imports, it might just reformat it. For goimports to change >> > anything semantically, the program would need to have missing imports to >> > begin with. >> >> Of course, you're right. I should have said: It can silently turn an >> invalid program into a valid one with different than intended/assumed >> semantics. Security implications, however, remain. >> > > I've experienced this (not in the sense of a security hole, but > unintended/expected semantic change) in developing my little toy GUI > wrapper. As I was writing in support for gotk3 after previously writing > support code for go-gtk (GTK2), the similarity in the two code-bases several > times lead goimports to bring in a mix of modules from the two different gtk > libraries, causing odd build errors and forcing manual fixes.
This happens quite often to me. I sometimes wonder if goimports could be cleverer about choosing packages when there are other imports close by (for some value of "close by") that satisfy the constraints. That applies to aliased packages too (in some code bases, some packages are almost always aliased for ambiguity or convenience reasons). -- 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.
