On Wednesday, 20 August 2014 at 20:39:06 UTC, Chris
Nicholson-Sauls wrote:
module foo.bar.one;
module foo.bar.internals; // package-protected utilities
module foo.bar.subpkg.two;
module foo.bar.subpkg.internals; // package-protected utilities
and module 'two' cannot access the 'bar' utilities.
Really? Looks like a bug. You'd better check if it's intended to
work that way.
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.
If some thing is used in entire foo.bar package, then it's
foo.bar's internal, not foo.bar.subpkg's internal. I think, it's
natural when the wider the thing is used, the higher in hierarchy
it sits.
I really don't see any equally strong counter-argument. But
then, I've wanted this exact fix for literally years now.
I don't really see, what it blocks.
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.
If those manipulators are used solely in loaders subpackage, they
should belong to that package. Though I don't really see a
problem here: there was an implementation of xml document, which
allowed unsafe (but fast) specialization, which was believed to
be useful for public usage. It fits well into D philosophy that
safe things should be available by default and unsafe/fast things
should be possible.
