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 or make "package <ident>" declaration optional #27820

Closed
matthewmueller opened this issue Sep 23, 2018 · 4 comments
Closed

Comments

@matthewmueller
Copy link

matthewmueller commented Sep 23, 2018

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!

@gopherbot gopherbot added this to the Proposal milestone Sep 23, 2018
@matthewmueller matthewmueller changed the title proposal: go 2 remove or make "package <ident>" optional proposal: go 2 remove or make "package <ident>" declaration optional Sep 23, 2018
@myitcv
Copy link
Member

myitcv commented Sep 23, 2018

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
Copy link
Author

matthewmueller commented Sep 23, 2018

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
Copy link
Contributor

cznic commented Sep 23, 2018

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
Copy link
Member

I will close this as a duplicate of #21479

@golang golang locked and limited conversation to collaborators Sep 23, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants