Go: proposal: Go 2: Implicit package name

[leonklingele]

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 that package statement it and make it implicit?

Example

$ pwd
$GOPATH/src/domain/myuser/somepackage
$ cat subpackage1/subpackage2/consts.go
package subpackage2 // Redundant, this _must_ always equal literally "subpackage2" (no quotes)

const (
    SomeConst = 42
)

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 your package main.

Is there something I'm not aware of which makes this change impossible?

[ianlancetaylor]

We can't remove the package declaration entirely, because it's necessary to distinguish tests that run in package x from those that run in package x_test.

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.

[leonklingele]

because it's necessary to distinguish tests that run in package x from those that run in package x_test

Oh, you're right. But there has to be a better solution than to mark __all__ files with a package statement. Either way, the tests (if not in the same package as the testees) need to be marked somehow.
Some possible solutions:

1. package x_test (which includes tests for package x). This is as it currently is. Not my favorite solution because again, it has package in it which I want to abstract away.
2. package test, simply drop the x_ prefix, otherwise same as 1. I prefer this to __1.__
3. Introduce a new keyword to mark such test files, e.g. test (probably a bad name) that needs to be the first non-comment token — the same as package is right now
4. Something else?

__EDIT__:
Fix typo.

[leonklingele]

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.

I have never used such a system and I guess a lot of others haven't as well.
Why can't they adapt? I'm asking this to be a feature of Go 2, which might well break existing stuff.
Making the package name _optional_ would work, those who want to use such a build system need to "annotate" their files as they already do right now.

Also the package declaration serves as a hook for the package common in godoc.

What do you mean by that? Why can't godoc adapt?

[davecheney]

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.

[leonklingele]

@davecheney

This saves at least two lines in every Go file which are redundant and make refactoring code harder

Why should anyone bother with package names? It's something you do not need, or do you?
Sure, my editor already auto-inserts an appropriate package name for new files, but what's the purpose of something which can be done automatically and implicitly?

[davecheney]

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.

[ianlancetaylor]

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.

[leonklingele]

@davecheney

this is a justification for your proposal, not the problem it solves

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.

There are cases where the packages decl cannot be inferred automatically for instance

Then simply _do_ add the package name to your files if you need them. Why should one be required to use them?

when the compiler is invoked directly without going through the Go tool

When is this the case? Don't you consider this to be edge-cases? Again, simply include them if you like to.

[coelho]

I've personally seen issues as well where a package declaration accidentally wasn't the correct package name (differed from the folder name) and nobody noticed because Go just accepts whatever is typed there. Was only an issue from the standpoint that it looked awkward and inconsistent. It really makes absolutely no difference and may as well be omitted in most cases.

[cznic]

As the package name of a file is always the name of the directory the file resides in (except package main), ...

The above was never true: s/always/most often/

[metakeule]

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

[bronze1man]

I think We can remove the package declaration entirely in go2.0
We also can make the package declaration optional in go1.10

• You can define main() function to mark as program entry point.
• You can use build flag to mark this file is belong to test.
• If you want to test the code in same directory in another package to workaround import circle, you can just move your test code to new directory.Thousands of directories and files is not a problem for today computer and os.

The package declaration is totally useless for me.
I think I should write a tool to auto correct and generate that line.
So that I can move and reflect code easier.

[andlabs]

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.

[bronze1man]

What refactoring is made easier by dropping package declarations?

Changing the last part of the package name become easier when the package declaration is deleted.

it is probably unwise to expect them to change the philosophies they have decided on.

I think the philosophies is made to solve problem to help developer, not make more problem.

[ianlancetaylor]

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.

[99yun]

Just remove the "package "