proposal: Go 2: remove dot imports from the language

[ianlancetaylor]

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.

[josharian]

While experimenting with #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.

[agnivade]

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.

[beoran]

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.

[alanfo]

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 golang/lint#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.

[deanveloper]

As per mentioned in #29036 (comment)

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.

[gotzmann]

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?

[bcmills]

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.

[bcmills]

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.

[deanveloper]

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

[natefinch]

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.

[networkimprov]

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.

[deanveloper]

@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.

[networkimprov]

Assignment redeclaration would also be flagged by Go2 vet :-)

[deanveloper]

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.

[ianlancetaylor]

@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.

[mikeschinkel]

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?

[rogpeppe]

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.

[mateuszmmeteo]

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?

[deanveloper]

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?

[creker]

@mateuszmmeteo why do you need dot import for that? Usually you write import _ "image/png" and let image.Decode figure out the rest.

[StephanVerbeeck]

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.

[mikeschinkel]

"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.

[ianthehat]

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

[StephanVerbeeck]

I am not happy that this issue still receives new debate.
If this option is removed that it destroys one of the greatest things in GO and it will break ALL MY EXISTING commercialized code!!!
As software developer this raving lunatics idealistic must-must-must goes not well by me.
There is a good reason why it is part of GO and that some do not wish to use it is their decision but I fail to see the need to enforce their misconceptions on the entire world.
This topic is not open for discussion any longer so close it and please finally decide AGAINST this idiotic request.
It is obvious that the original poster is not aware of the magnitude of financial damage that he demands for.
Don't make us regret using GOlang for commercial main products.
Please end this topic!

[zigo101]

This can be viewed as feature removal. If your go.mod file specifies an old version in the go directive, then the old code will still compiles by using the newest Go toolchain.

And go fix will help you transit without much effort.

[mateuszmmeteo]

Maybe it’s time to fork Golang project…?

[beoran]

If this issue is accepted, I will name all my dsl packages ᣟ, to be able to get a short, almost invisible import name again. With my excuses to the Canadian Aboriginals.

It goes like this:
ᣟ.go:

package ᣟ

import "fmt"

func Yes() {
	fmt.Printf("yes\n")
}

ᣟ_test.go:

package ᣟ_test

import "applied-maths.com/bnxt/platform/ᣟ"
import "testing"

func TestYes(t *testing.T) {
	ᣟ.Yes()
}

[ianlancetaylor]

@StephanVerbeeck Please be polite and respectful and follow the Go Community Code of Conduct. Thanks.

[beoran]

@ianlancetaylor I think we should advance this issue through the proposal process more rapidly. It's been open for over 2 years now without making much progress and this for a feature of Go that is already widely used.

However, as we can see from the emoticon poll and the various discussions, there is no consensus over this issue neither in favor or against it. Perhaps it's time to apply the rule from https://github.com/golang/proposal "If general consensus cannot be reached, the proposal review group decides the next step by reviewing and discussing the issue and reaching a consensus among themselves."? Or should this proposal be placed on "hold"?

[ianlancetaylor]

@beoran This is an incompatible change, so it follows a different process, one that admittedly tends to move more slowly. This is indicated by the Go2 label.

[beoran]

@ianlancetaylor I see, I didn't know that. how is the Go2 process different? I looked around and I could find #33892 as the umbrella issue that is tracking this, but not a formal description of the go2 process. Is that different process already formalized and written down anywhere, and if so could you refer us to it, so we can have an idea of how this issue will progress?

[ianlancetaylor]

It's a much more casual process, since the bar for incompatible changes is much higher. We haven't tried to formalize it.

[StephanVerbeeck]

I guess the problem most programmers have with dot-import is not the principle.
Rather I guess they have issues with the fact that code intellisense does never implement it (not working in visual studio code) so Go-users consider the dot-import to be broken while it is rather the code intellisense that is broken.
It is indeed a nuisance that goto-definition is not working for these where this is clearly a decision of the implementor to ignore this because he/she himself/herself is not using it.
So maybe the solution to this topic is to finish the last 10% work rather than undoing the working 90%.

[drekle]

Rather I guess they have issues with the fact that code intellisense does never implement it (not working in visual studio code) so Go-users consider the dot-import to be broken while it is rather the code intellisense that is broken.

I use intellisense and goto-definition and they are very convenient, however as a matter of principle I don't think advanced features of any IDE should be relied on to solve code readability issues caused by dot imports.

[rvolosatovs]

I find dot imports extremely useful in internal packages.

Given a package A:

• A/B and A/C contain implementations of interfaces defined in A.
• A/internal contains utilities used by A, A/B and A/C
• A/internal/test contains test utilities used by A_test, A/B_test and A/C_test
• A/internal/test/shared contains test utilities used by A/B_test and A/C_test

The dependency graph looks like this (LHS is the (sub-)package, RHS are the dependencies)

• A -> { A/internal }
• A/B -> { A, A/internal }
• A/B_test -> { A/B, A/internal/test, A/internal/test/shared }
• A/C -> { A, A/internal }
• A/C_test -> { A/C, A/internal/test, A/internal/test/shared }
• A/internal -> { }
• A/internal/test -> { A/internal }
• A/internal/test/shared -> { A }

For example, see the following package with such structure (A being pkg/networkserver, and A/B being pkg/networkserver/redis)
https://github.com/TheThingsNetwork/lorawan-stack/tree/bb0f4c7cc2c8c71efe4140ac9078cfb2ee1ddba2/pkg/networkserver

While importing A/internal as internal makes sense in implementation code, importing A/internal/test and A/internal/test/shared named makes less sense and probably requires aliases to avoid clashes with e.g. external pkg/test. Dot imports make this way cleaner and clearer

[jindanupajit]

Instead of removing 'dot import', consider adding compiler option to incorporate custom coding style spec. Each project will compile with those spec which allow or restrict 'dot import' or anything else.

[the-zucc]

Go is a beautiful language, because it gives developers a lot of freedom, while having strict guidelines and principles. Its ecosystem is also what makes go so special.

Very neat internal utilities can be created using dot imports, allowing skilled developers to write small modules that can almost act as extensions of the Go builtins; this allows very succinct code to be written. I don't see why the support for these would need to be removed in future Go versions. Is there a concrete technical or functional reason for it, or is it purely based on principle ?

A language, fundamentally, allows its speakers to communicate effectively and conveniently. Intervening and removing something that is convenient for some speakers is totalitarian, and should almost never be done, and even when done, it should only be with extreme care.

I understand that removing dot imports would make some Go project contributors happy, but, just like in general you wouldn't ban a syntax or word entirely from the English language (or any language whatsoever), you shouldn't ban some syntax from a programming language either.

I sincerely hope that this proposal will get rejected, as it doesn't add anything to anyone, except appease some purists who, frankly, just need to look at the imports a bit, and hover their mouse over function names in their IDE.

[atdiar]

One use-case I thought about and that I almost went and tried today is allowing for a package to expose an API with different implementations via build constraints.

So depending on the build tag, a package implementation would differ, via the dot import. (the package in question was syscall/js, basically needed an alternate implementation when building for SSR)

Not unlike aliasing but coarser. Is this a relevant use-case?

Another case of adding a layer of indirection to solve a problem? ;o)

[S-YOU]

I am ok with not having those in Go v2, but let me share my usage about dot import currently.

I have GraphQL on front side and SQL on DB side.
I would like share Enums which type defined like this, for example.

type Role string

const (
	RoleAdmin  Role = "admin"
	RoleEditor Role = "editor"
	RoleUser   Role = "user"
	RoleGuest  Role = "guest"
)

With dot import it is really convenient you can just use RoleAdmin or RoleGuest on both layer,
and it is much easier for code generations, which does not need to know details or receiver/pkg's type.
Also having those in separate package, you can import from anywhere without worrying about cyclic imports.
You may think that I should use Role as Int, but that is another story.

[ianlancetaylor]

It's clear that there are people using dot imports today, including the standard library. Banning dot imports today would break those users. The advantage of banning dot imports is cleaner code. But there are many ways to write code that is hard to understand, and dot imports are just one way. So this proposal isn't worth doing, at least not by itself. Closing.