module foo.bar.internals; // package-protected utilities
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.