go
go copied to clipboard
golang
proposal: Go 2: remove dot imports from the language
This issue is broken out of #29036.
We should remove dot imports from the language (import . "path"). Quoting @rogpeppe:
The official guidelines suggest that a dot import should only be used "to let the file pretend to be part of package foo even though it is not". This is a stylistic choice and strictly unnecessary. The tests can still use package-qualified names with only minor inconvenience (the same inconvenience that any external user will see).
Other than that, I believe the most common use is to make the imported package feel "close to a DSL". This seems to be actively opposed to the aims of Go, as it makes the programs much harder to read.
While experimenting with https://github.com/golang/go/issues/20104 just a few days ago, dot imports were incredibly useful—instead of having to plumb a bunch of context through complicated code generation scripts and carefully conditionally adjust a dozen format strings, I could just dot import ssa in the relocated files. Long term, I would choose to do the work to eliminate the dot import. But it was very helpful as scaffolding. And not just for experimentation: the dot import is a single line change for reviewers, whereas qualifying every package use would have made the diff unreadable (and unrecognizable to git as a file move).
To be clear (unlike type aliases), this kind of refactoring is strictly speaking possible without dot imports. It is just a lot more graceful with them.
Other than that, I believe the most common use is to make the imported package feel "close to a DSL".
Yes, this is what Goa does; which is used by a lot of people. If we remove dot imports, the entire package will break.
I have no issues either way. Just wanted to point this out.
DSLs are an important use case for dot imports, I disagree that DSLs make programs harder to read. On the contrary, they make programs easier to read for specific types of program, such as the Goa examples shows, and more importantly also make a program easier to understand for non-programmer domain experts for whom the DSL has been designed. This is why I respectfully ask that this proposal be rejected.
Although dot imports are a feature which should be used sparingly, I can't see the sense in banning them altogether.
There are definitely occasions when they are useful for testing and experimentation and there are some other reasonable uses as well - see for example https://github.com/golang/lint/issues/179.
I often use them myself when importing the math package, so I can just write Cos instead of math.Cos. Admittedly this isn't the greatest of use cases but, for me at least, there is no risk of confusion as I would never use the names of math functions as public names in my own packages.
As per mentioned in https://github.com/golang/go/issues/29036#issuecomment-443259313
I've found dot-imports to be useful when writing tests. For instance:
package mypack_test import . "github.com/deanveloper/mypack" // ...I wouldn't really mind the dot-import being removed. I was just adding my particular use case for them.
And to reiterate, I wouldn't mind dot-import being removed. It's just what I use them for.
Most of the popular programming language use some form of "dot import" without any hassles. Hows ftm.Printf is more clear then simple print or echo?
Tests are a great argument for removing dot-imports. I've seen lots of tests that failed to catch extremely redundant identifiers, because the tests and examples didn't include the package name as everyone else would.
At first glance math seems like a great argument for not removing them, but then consider functions like Jn, Y0, and Log: the former two are somewhat obscure, and the latter could easily collide with a similarly-named function in another package. I could see a reasonable argument for dot-importing trigonometric functions and rounding functions, but math overall seems like a bit of a stretch.
Hmm now that I think of it, I feel like I've heard a lot of this stuff before. I feel like this might be a duplicate, but I searched for proposals of removing dot imports but didn't find anything
Dot imports make your code lie. That's Bad.
When you write AssertEqual(t, got, expected) and your current package doesn't have an AssertEqual function... that code is lying. If you're reading that in a code review (i.e. not in an IDE with hover text etc), you would not be crazy to think AssertEqual is some function in the current package.
Also, if you then copy that code to a different file in the same package... it will fail to compile, and there's nothing goimports can do to figure out where AssertEqual comes from. So you have to Just Know™ where it comes from and add the import yourself. That's bad, too.
I don't believe DSLs of the type made popular in dynamic languages such as python and ruby belong in Go. Those languages specifically give you tools so that you can make non-native functionality look like native functionality. Those languages intentionally let you play fast and loose with types and what the code actually does when you type foo += bar can be vastly different depending on what foo and bar are. Go is not that language. foo += bar will always be simple to understand in Go. There's only a couple things it can possibly mean.
DSLs sacrifice clarity of what the machine is doing for clarity of what the code says. That's not Go's way. You should not need external context to understand where an identifier comes from and what it is calling or doing.
Maybe the proposal should be "flag dot imports with go vet"?
@ianlancetaylor and others have asserted that Go2 shall not break existing code except where unavoidable for essential new features.
@ianlancetaylor and others have asserted that Go2 shall not break existing code except where unavoidable for essential new features.
This seems to be his proposal, haha. I think that if there's a consensus that a feature is actively harmful that it should be (at least) considered for removal. IIRC Russ Cox (maybe it was Rob Pike) have talked about removing shadowing if we get the check keyword.
For now, yes, but what I was trying to say is that a full removal of a feature is something we have already considered (and seem to still be considering, looking at this proposal). Saying that significant members "have asserted that Go2 shall not break existing code [...]" makes it sound like feature removal is something that shouldn't even be listened to, rather than something we'd rather not do.
@deanveloper I should clarify that although I opened the issue, it's really @rogpeppe 's proposal. I split out of #29036 to clarify that issue.
Personally I'm somewhat against this proposal because I don't think the benefit of clearer code is worth the cost of breaking existing packages. But I'm willing to be convinced otherwise.
I literally just learned about dot imports last week, and have been looking forward to using them in the future, mostly for the handful of random helper functions which can typically be isolated to one package. That way I can write more compact code that uses those helper functions and the code would be easier to reason about for me or anyone who pays attention to the imports.
Idea: If you want to do away with dot imports, consider allowing only one dot import per file?
For the record, the reason I bundled this issue up with #29036 was that it's necessary to do this if we want to make all imported symbols predictable, which is, I believe a useful property to have globally.
I sympathise with the use of dot imports in @josharian's scenario, but I see it as somewhat of a niche case, which surely could be addressed with a little more additional tooling to make it easier to package-qualify chosen identifiers in generated code. Getting git to recognize diffs of files that move between packages is often a problem anyway. There are many such cases where code is refactored and the diffs are large because the package qualifiers change. I see that as the more general problem here, and dot-imports aren't a good solution in most such cases.
In short, I think that the readability advantages of having properly qualified identifiers everywhere outweigh the occasional extra burden of adding the qualifiers.
In my case during image manipulations I'm often using "." import as possibility to load JPEG (image/jpeg) or PNG (image/png) lib. Without "dot import" this library will be removed and I cannot use jpeg.Encode() method.
How do you want to solve such issue?
I don't understand your issue, can you provide an example? How are you using dot imports and why can't you just use jpeg.Encode?
@mateuszmmeteo why do you need dot import for that? Usually you write import _ "image/png" and let image.Decode figure out the rest.
I am currently using lxn/walk which has a declarative package for defining forms. Removing the "." import would brake ALL EXISTING code that uses this package. And I personally would be very angry having to write "declarative.Button" instead of "Button". I would have to write the name of the package several thousand times to be exact. That is not my idea of making code more readable, seems to be more an idea of enforcing restrictions for which I see not a point that they should exist. The original designer who created the dot-import was correct in providing this functionality.
On the other hand, every programmer should also have the common sense to NOT have multiple dot-imports in the same GO-source. Because as long as there is only one dot-import it is PERFECTLY clear as to where the methods and types belong.
I would even go further to request that the intellisense of "Visual Studio Code" be improved to understand this.
"I would even go further to request that the intellisense of "Visual Studio Code" be improved to understand this."
Just FYI, GoLand already supports auto-complete on dot imports.
And I personally would be very angry having to write "declarative.Button" instead of "Button".
I agree with this in general with Go. There are a lot of cases when I really wish I could forgo having to prefix with a package name. I know this is a tangent but it would be great if we could define an alias like so:
type Button alias declarative.Button
Another thing that would be great is if Go would assume the same package when other members of the package are passed in to a func call with a simple dot prefix, e.g. instead of this:
forms.ShowDialog("Do you want to close?" forms.Yes, forms.No, forms.Cancel)
It would be great if Go assume the follow was equal to the previous:
forms.ShowDialog("Do you want to close?", .Yes, .No, .Cancel)
I'll be happy to break these two requests out into new tickets assuming I get positive reactions from those on the Go team.
I agree with this in general with Go. There are a lot of cases when I really wish I could forgo having to prefix with a package name. I know this is a tangent but it would be great if we could define an alias like so:
type Button alias declarative.Button
type Button = declarative.Button
works, but will give you an exported symbol, you can always do
type button = declarative.Button
if you don't want that
See https://golang.org/ref/spec#Alias_declarations
@ianthehat Interesting. Clearly I did not know that. Thank you!
(So much still to learn about Go...)
I would go with quite opposite (remove it - it will reduce readability. Example below). Let's say that you have multiple packages that implement "Client" struct. That's most cases in my experience. In code I can use multiple of them. For example:
httpClient,err := http.Client(http.MethodGET, URL, parameters)
...
cacheClient,err := redis.Client(config.RedisConnenctionString)
...
cloudWatchLog,err := logging.Client(config.AWSSdkCredentials)
...
sqlClient,err := mysql.Client(config.SqlDbConnectionString)
We could use builders and define NewHttpClient(params).Build(), NewCacheClient(params).Build()... or we could do it manually in code what would make project code grow.
In code you're seeing what you're touching - don't need to make additional import aliasing. Don't see solution for that. Calling variables and base on that variable name? That would be unwise.
@mateuszmmeteo
"I would go with quite opposite"
Even after reading your code it is not clear to me what you are suggesting.
Calling variables and base on that variable name? That would be unwise.
How would it be unwise if the rule is the following?
"Any parameters prefixed with a simple dot (
.) would inherit the package of the func being called."
As proposed it is 100% unambiguous.
@mikeschinkel
@mateuszmmeteo
"I would go with quite opposite"
Even after reading your code it is not clear to me what you are suggesting.
Calling variables and base on that variable name? That would be unwise.
How would it be unwise if the rule is the following?
"Any parameters prefixed with a simple dot (
.) would inherit the package of the func being called."As proposed it is 100% unambiguous.
In my example you would be required to write:
httpClient,err := .Client(http.MethodGET, URL, parameters)
...
cacheClient,err := .Client(config.RedisConnenctionString)
...
cloudWatchLog,err := .Client(config.AWSSdkCredentials)
...
sqlClient,err := .Client(config.SqlDbConnectionString)
Do I understand you correctly?
@mateuszmmeteo
No, that is not what I proposed. My proposal would not be applicable to your example.
Examples that would be applicable, by searching for examples in the Go SDK:
Currently:
f,err = os.Open(os.DevNul)
http.Handle("/tmpfiles/", http.StripPrefix("/tmpfiles/", http.FileServer(http.Dir("/tmp"))))
out = strings.ReplaceAll(strings.ReplaceAll(strings.TrimSuffix(out, "\n"), " ", ""), "\n", " ")
Using proposed:
f,err = os.Open(.DevNul)
http.Handle("/tmpfiles/",.StripPrefix("/tmpfiles/",.FileServer(.Dir("/tmp"))))
out = strings.ReplaceAll(.ReplaceAll(.TrimSuffix(out, "\n"), " ", ""), "\n", " ")
To clarify:
-
os.Open()means you can dropos.from.DevNul -
http.Handle()means you can drophttp.from.StripPrefix() -
http.StripPrefix()means you can drophttp.from.FileServer() -
http.FileServer()means you can drophttp.from.Dir() -
strings.ReplaceAll()means you can dropstrings.from.ReplaceAll() - The 2nd
strings.ReplaceAll()means you can dropstrings.from.TrimSuffix()
Is that clearer?
It would be a small change/help, but it would be nice for those cases where you are using a lot of package prefixed consts and vars as parameters.
I'm still thinking about interfaces and multiple implementations that you can use as parameters but yes, looks good.
@mikeschinkel I think your proposal is pretty different than what @rogpeppe had in mind. If you’d like to pursue it, please open a new issue so we can keep the threads distinct. One question you could answer there is: Given a.F(b.G(.X)), is X from package a or b?