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: remove package keyword #41788

Closed
ivanjaros opened this issue Oct 5, 2020 · 2 comments
Closed

proposal: remove package keyword #41788

ivanjaros opened this issue Oct 5, 2020 · 2 comments
Labels
Milestone

Comments

@ivanjaros
Copy link

@ivanjaros ivanjaros commented Oct 5, 2020

Presently the "package" is required in each go file. The package dictates the name of the library when imported somewhere else. Often it matches the directory name of the package but not always. In these cases when a library is imported this defined package must be used to call the code from this library instead of the name of the directory.

For example:

file: github.com/foo/bar/bar.go
package "bar"

func DoSomething() {}

file: github.com/foo/baz/baz.go
package "baz"

import "github.com/foo/bar"

func Bar() {
  bar.DoSomething()
}

vs

github.com/foo/bar2/bar.go
package "bar"

func DoSomething() {}

github.com/foo/baz/baz.go
package "baz"

import bar "github.com/foo/bar2"

func Bar() {
  bar.DoSomething()
}

I think the package keyword should be made optional, only for backwards compatibility, and the directory of the go files should be assumed as package name automatically. This will allow us to simplify refactoring(just rename a directory instead of all uses of the package keyword in that directory), plus it will simplify refactoring imports - there will no longer be a need to scan the imported library and look for the package name, instead the directory name will be used right away. If two packages with the same directory are imported, import aliasing still works like before.

Some may say that package keyword is required for the build functionality, but I think that, since main() is a magic function name, whenever a package contains this method, it should be automatically assumed it is the main package(build/functionality-wise, not name-wise..unless the directory is called main, of course) and can be compiled into executable and does not have to be specifically named as main.

@gopherbot gopherbot added this to the Proposal milestone Oct 5, 2020
@gopherbot gopherbot added the Proposal label Oct 5, 2020
@go101
Copy link

@go101 go101 commented Oct 5, 2020

This was proposed before. Someone like it, someone don't.

@ivanjaros
Copy link
Author

@ivanjaros ivanjaros commented Oct 5, 2020

ok, thanks. it is hard to find duplicates with 5k open issues.

@ivanjaros ivanjaros closed this Oct 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.