Module Clarification

[Lodovico Giaretta via Digitalmars-d-learn]

On Thursday, 22 September 2016 at 14:29:20 UTC, Jonathan Marler 
wrote:
> Actually, the more I think about it, I'm not sure there's a 
> good reason for the "package.d" semantics to exist.  I guess it 
> establishes a pattern when people would like to combine smaller 
> modules into one public module, but it doesn't have to be used 
> that way.  The opposite is true that you could use a normal 
> module (not a package.d module) to publicly import smaller 
> modules:
>
> Instead of:
> foo/package.d // publically imports fooPart1 and fooPart2
> foo/fooPart1.d
> foo/fooPart2.d
>
> What was wrong with:
> foo.d // still publically imports fooPart1 and fooPart2
> foo/fooPart1.d
> foo/fooPart2.d
>
> If the package.d file didn't exist, then I don't think there 
> would be any problem with hierarchical modules.  Is this the 
> right conclusion?  Was package.d a mistake?  Maybe the 
> reasoning is that D doesn't really like hierarchical modules, 
> so creating them should look a bit odd?
>
> foo/package.d
> foo/bar/package.d
> foo/bar/baz/package.d

I think that having package.d provides a better layout. Look at 
the difference between this:

> ls std/experimental
drw-rw-rw- allocator
drw-rw-rw- logger
drw-rw-rw- ndslice
-rw-rw-rw- typecons.d

and this:

> ls std/experimental
drw-rw-rw- allocator
-rw-rw-rw- allocator.d
drw-rw-rw- logger
-rw-rw-rw- logger.d
drw-rw-rw- ndslice
-rw-rw-rw- ndslice.d
-rw-rw-rw- typecons.d

Having to put part of a package outside the package folder is 
ugly to see and a bit more difficult to manage.