-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: Implicit package name #21479
Comments
We can't remove the Also there are build systems for Go other than the go tool, such as Bazel, and those systems do not use the same directory layout. Also the package declaration serves as a hook for the package comment in godoc. I suppose that we could make the package declaration optional. |
Oh, you're right. But there has to be a better solution than to mark all files with a
EDIT: |
I have never used such a system and I guess a lot of others haven't as well.
What do you mean by that? Why can't godoc adapt? |
Leon, what do you want to accomplish with this proposal? What are the problems, in your experience, you have encountered with the package declaration? It may be possible to address your issues in another way. |
Why should anyone bother with package names? It's something you do not need, or do you? |
Leon, this is a justification for your proposal, not the problem it solves. There are cases where the packages decl cannot be inferred automatically for instance, when the compiler is invoked directly without going through the Go tool. |
The godoc issue is simply that we want to have a way to provide a comment that describes a package. You see these comments on https://godoc.org, for example. Right now godoc displays the comment adjacent to the package declaration (with the expectation that there is only one such comment in a multi-file package). If there is no package declaration, godoc needs some other mechanism for designating the package comment. A separate build system like bazel can't adapt because they permit multiple Go packages per directory, and because they permit files to be generated at build time. |
it makes refactoring harder, it introduces "complexity" (ok, maybe I'm exaggerating a bit) where complexity is not required. Isn't that enough? Something which is not required necessarily shouldn't be required strictly.
Then simply do add the package name to your files if you need them. Why should one be required to use them?
When is this the case? Don't you consider this to be edge-cases? Again, simply include them if you like to. |
I've personally seen issues as well where a |
The above was never true: s/always/most often/ |
You could make the package name optional when it matches the directory name. That should cover all cases and behave exactly as today. Parsers not having access to the path should get the name passed in. I am in favor of the proposal because it makes refactoring easier in early stages (=pre release) of development (e.g. split out files to sub packages etc). |
I think We can remove the package declaration entirely in go2.0
The package declaration is totally useless for me. |
What refactoring is made easier by dropping package declarations? Ian has repeatedly told you one thing that invokes the Go compiler directly: the Bazel build system. Considering who makes Bazel, it is probably unwise to expect them to change the philosophies they have decided on. |
Changing the last part of the package name become easier when the package declaration is deleted.
I think the philosophies is made to solve problem to help developer, not make more problem. |
I think there are enough reasons here to show that the package clause can not simply be eliminated in Go 2 without requiring various related changes. The benefits of eliminating the package clause seem small. We could make the package clause optional under certain conditions, but that seems to make things more complicated. People will start writing style guides about when the package clause should exist, or not. Files may sometimes change behavior when they change directories. The additional complexity seems not worth the benefits. |
Just remove the "package " |
Proposal
As the package name of a file is always the name of the directory the file resides in (except package
main
), why not remove thatpackage
statement it and make it implicit?Example
This saves at least two lines in every Go file which are redundant and make refactoring code harder (because you need to adjust the package name when moving the file to a different directory == different package).
I assume this can easily be implemented in the Lexer which just dynamically generates and spits out the additional two(?) tokens.
What to do about "package main"?
Well, as http://www.monogrammedchalk.com/go-2-for-teaching/ suggests, just use the package which defines
func main() {
as yourpackage main
.Is there something I'm not aware of which makes this change impossible?
The text was updated successfully, but these errors were encountered: