Module Clarification

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/21/16 10:17 AM, Jonathan Marler wrote:
> I'm working on a code generation tool and wanted to make sure my module
> approach was correct.  The generated code has a module hierarchy, where
> modules can appear at any level of the hierarchy.
>
> module foo;
> module foo.bar;
>
> In this case, module foo and foo.bar are independent modules.  The foo
> module does not publicly import foo.bar, like a typical package.d module
> would do. At first I organized the modules like this:
>
> foo.d     (module foo)
> foo/bar.d (module foo.bar)
>
> But this doesn't work because the module file foo.d, cannot have the
> same name as a the directory foo.  So now I organize it like this:
>
> foo/package.d (module foo)
> foo/bar.d     (module foo.bar)
>
> This is not the typical usage for the "package.d" file.  Normally,
> package.d would publicly import other modules, however, in this case,
> package.d is an independent module.

This is not a requirement for the package.d usage. You can do anything 
you want in package.d

For example, in std/experimental/allocator/package.d, sub modules are 
not imported unless you do it yourself.

>  This also means that if another
> module was added, say foo.bar.baz, the new file system would have to
> look like this:
>
> foo/package.d     (module foo)
> foo/bar/package.d (module foo.bar)
> foo/bar/baz.d     (module foo.bar.baz)
>
> This technique seems a bit odd, but it works.  I'm just wondering if
> there's a better way to achieve these semantics, or if this is the
> appropriate solution?

This should be fine. x/package.d is equivalent to module x.

-Steve