4 ms·

Putting a type into a type-specific package like that is considered (IMHO at least) unidiomatic in the first place, so this isn't a situation which can happen i

• frou_dh 7y ago
  What's the counterargument to the expressed benefit?
  • klodolph 7y ago
    It breaks the ability to Ctrl-F to find uses of the package foo. It’s surprising to other Go programmers. If you’re working by yourself, go wild and do what you want. On teams, I’m much more likely to need to search through somebody else’s file to understand it or find something. It also means that additions to foo might conflict with definitions in your package. The reason this feature exists is to break circular dependencies in unit tests. So in foo_test, you might import ( . "foo" "fooutil" )
    • frou_dh 7y ago
      This makes sense but it's more like general advice for why typical packages should not be import-dotted. I was talking about a very specific kind of low-pollution package that will export essentially nothing bar a single type (maybe a NewFoo constructor too). The package isn't a bucket, it's a barrier. (I hope people move beyond ctrl-f/grepping, to tooling that has semantic understanding of definitions/references. Go go gopls & GoLand!)
      • klodolph 7y ago
        If you already have the answer, why are you asking the question? (You can’t find Foo just by looking at syntax at all, you would need to parse both the package where it is used and the package where it is defined. Using normal imports, you can get by with only parsing the call site.)