Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Go 2: remove dot imports from the language #29326

Open
ianlancetaylor opened this Issue Dec 18, 2018 · 21 comments

Comments

Projects
None yet
@ianlancetaylor
Copy link
Contributor

ianlancetaylor commented Dec 18, 2018

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

This comment has been minimized.

Copy link
Contributor

josharian commented Dec 19, 2018

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

This comment has been minimized.

Copy link
Member

agnivade commented Dec 19, 2018

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

This comment has been minimized.

Copy link

beoran commented Dec 19, 2018

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.

@Allenyn

This comment has been minimized.

Copy link

Allenyn commented Dec 19, 2018

I think, why do't import file level ,replace import package, just like python.

Is that a better way ??

@alanfo

This comment has been minimized.

Copy link

alanfo commented Dec 19, 2018

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

This comment has been minimized.

Copy link

deanveloper commented Dec 19, 2018

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

This comment has been minimized.

Copy link

gotzmann commented Dec 19, 2018

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

This comment has been minimized.

Copy link
Member

bcmills commented Dec 19, 2018

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

This comment has been minimized.

Copy link
Member

bcmills commented Dec 19, 2018

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

This comment has been minimized.

Copy link

deanveloper commented Dec 19, 2018

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

This comment has been minimized.

Copy link
Contributor

natefinch commented Dec 19, 2018

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

This comment has been minimized.

Copy link

networkimprov commented Dec 19, 2018

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

This comment has been minimized.

Copy link

deanveloper commented Dec 19, 2018

@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

This comment has been minimized.

Copy link

networkimprov commented Dec 19, 2018

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

@deanveloper

This comment has been minimized.

Copy link

deanveloper commented Dec 19, 2018

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

This comment has been minimized.

Copy link
Contributor Author

ianlancetaylor commented Dec 19, 2018

@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

This comment has been minimized.

Copy link

mikeschinkel commented Dec 30, 2018

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

This comment has been minimized.

Copy link
Contributor

rogpeppe commented Dec 30, 2018

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

This comment has been minimized.

Copy link

mateuszmmeteo commented Jan 29, 2019

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

This comment has been minimized.

Copy link

deanveloper commented Jan 29, 2019

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

This comment has been minimized.

Copy link

creker commented Jan 30, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.