proposal: go 2 remove or make "package <ident>" declaration optional

[matthewmueller]

Since the folder structure generally dictates what your package name will be, it might be nice to remove the extra package <ident> declaration. For backwards compatibility, package <ident> could be optional.

One issue is when you use hyphens like foo-bar/foo-bar.go has package foobar, but I'd consider that generally bad practice anyway.

Another consideration is tests, but in that case we could use the filename *_test.go to dictate the package name. There may also be issues with package main, but could maybe default to the filename main.go as defaulting to package main.

I'm probably not be considering all the cases, but it does seem quite repetitive in general and it doesn't seem to add much, if anything it adds confusion when your package name isn't the same as your file directory. This is especially true when refactoring.

I'm curious to hear what you all think!

[myitcv]

To add to the list of issues, there is that of external tests, e.g. package pkg_test along side package pkg.

The main.go idiom also seems rather magic when considered alongside the explicit package main (which is necessary as discussed to distinguish from package main_test).

@matthewmueller what are you trying to solve for here?

[matthewmueller]

To add to the list of issues, there is that of external tests, e.g. package pkg_test along side package pkg.

I haven't been around since Go's inception but it seems like package pkg_test is generally better practice when you have the file pkg_test.go. There do seem to be certain cases where you need to test private functionality and using package pkg inside pkg_test.go is necessary, but that seems like an edge case and less relevant with concepts like internal/ nowadays.

To clarify the original post, pkg_test.go without a package <ident> would be end up being package pkg_test not package pkg.

The main.go idiom also seems rather magic when considered alongside the explicit package main (which is necessary as discussed to distinguish from package main_test).

Fair point! Though I personally find pkg_test.go and things like pkg_darwin.go about as magical as a main.go concept. I'd see this more as solidifying what we all generally do anyway inside cmd/<cmdname>/main.go.

@matthewmueller what are you trying to solve for here?

Further distilling the language to only the essentials.

The initial motivation for writing this was I was renaming a folder with a ton of go files in it. As we all know, you have to rename all the package pkg to the new folder name. That got me wondering how necessary it was.

I'm stepping out of my depths a bit here, but I'm pretty sure there's precedence for folder-based packaging in languages like ocaml. It seems like Go is more than halfway there with its best practices encouraging it. This would codify it.

[cznic]

The initial motivation for writing this was I was renaming a folder with a ton of go files in it. As we all know, you have to rename all the package pkg to the new folder name.

I don't know that. AFACT, There's no restriction on the package name that's related to name of directory holding that package.

[dominikh]

I will close this as a duplicate of #21479