nested module problem

[Jean-Louis Leroy via Digitalmars-d-learn]

On Saturday, 2 September 2017 at 21:42:59 UTC, Moritz Maxeiner 
wrote:
> On Saturday, 2 September 2017 at 21:24:19 UTC, Jean-Louis Leroy 
> wrote:
>> [...]
>
> Yes, these now both fail because you cannot have a module `foo` 
> and a package `foo` at the same time (they share a namespace), 
> I forgot about that.
>
>> [...]
>
> (same as before, no issue here)
>
>> [...]
>
> You created the 'foo' package by specifying `module foo.bar` in 
> foo/bar.d.
>
>> [...]
>
> AFAIK you can't; consider:
>
> -- baz.d ---
> import foo;
> ------------
>
> in the same directory as foo.d. If foo/package.d exists (with 
> `module foo` inside), what should baz.d import? foo.d or 
> foo/package.d?
> The point being that we could have either used foo/package.d or 
> foo.d for a package file, but not both (as that would allow 
> ambiguity) and package.d was chosen.
>
> [1] https://dlang.org/spec/module.html#package-module

Hmmm I see...I was thinking of spinning the runtime part of my 
openmethods library into its own module (like here 
https://github.com/jll63/openmethods.d/tree/split-runtime/source/openmethods) but it looks like a bad idea...