Module Clarification

[Jonathan Marler via Digitalmars-d-learn]

On Thursday, 22 September 2016 at 15:02:01 UTC, Lodovico Giaretta 
wrote:
>
> 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.

Yes that does seem like a nice benefit.  What do you think about 
hierarchical modules?  Do you think we should have supported 
modules that also have modules underneath them? i.e.

foo.d
foo/bar.d
foo/bar/baz.d

Or do you think it's fine to require the higher level modules to 
exist in package.d files?

foo/package.d
foo/bar/package.d
foo/bar/baz.d

It just seems odd because the modules aren't packages.  I suppose 
I would understand if hierarchical modules are discouraged, is 
that the case?  I ran into this problem because I'm working on a 
.NET to D transpiler, and put all the symbols in a .NET namespace 
into the same D module.  So currently I have to do this:

System/package.d
System/Net/package.d
System/Net/Sockets.d

but I think it would make more sense to have this:

System.d
System/Net.d
System/Net/Sockets.d