Go: proposal: allow cyclic imports within one module (or within the same direct parent package)

[go101]

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.

[bcmills]

See previously #30247.

[griesemer]

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

[go101]

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