module foo.bar.one; module foo.bar.internals; // package-protected utilities module foo.bar.subpkg.two; module foo.bar.subpkg.internals; // package-protected utilities
Current situation: module 'one' cannot access the 'bar.subpkg' utilities, and module 'two' cannot access the 'bar' utilities. This is needlessly limiting, forcing design choices that should not be dictated by the ability/inability to separate public and private API. It also precludes many valid and good uses of nested package.d modules.
I really don't see any equally strong counter-argument. But then, I've wanted this exact fix for literally years now.
It also is not limited to internal utility modules. It can be useful for systems that select at compile time from one of a number of system-specific implementations of a given interface/api. It can be useful for granting privileged access to certain api's and/or resources to specific module(s). An example being: grant access to unsafe but versitile data manipulators solely to the subpackage containing the loaders.
Currently, there is no absolutely enforceable way of doing such things; so one ends up falling back on convention... and conventions, sadly, never hold in the real world for long.
