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: allow cyclic imports within one module (or within the same direct parent package) #31833

Closed
go101 opened this issue May 4, 2019 · 3 comments
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Milestone

Comments

@go101
Copy link

go101 commented May 4, 2019

Although I oppose to supporting arbitrary cyclic imports, I feel sometimes it is really a need to support cyclic imports within a limited scope.

Sometimes, to avoid cyclic imports, many types and functions must be put in the same package, which makes the package huge and bloated. On the contrary, splitting the huge package into some small packages which are still in one module will make code management much easier and improve docs reading much. To make this feasible and avoid the drawbacks of cyclic imports, we can limit cyclic imports within one module, or even more limited, within the same direct parent package (and one module).

So I made this proposal.

@gopherbot gopherbot added this to the Proposal milestone May 4, 2019
@go101 go101 changed the title proposal: allow cyclic imports within one module proposal: allow cyclic imports within one module (or within the same direct parent package) May 4, 2019
@bcmills
Copy link
Contributor

bcmills commented May 6, 2019

See previously #30247.

@bcmills bcmills added v2 A language change or incompatible library change LanguageChange labels May 6, 2019
@griesemer
Copy link
Contributor

Sorry, but no. We have deliberately chosen to disallow import cycles both for human understanding and implementation simplicity.

@go101
Copy link
Author

go101 commented May 29, 2019

@griesemer
Is there a plan to solve the bloating package problem?
This problem is more serious for some cgo projects, in which almost all types and functions must be put in one huge package.

@golang golang locked and limited conversation to collaborators May 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Projects
None yet
Development

No branches or pull requests

4 participants