nested module problem

[Moritz Maxeiner via Digitalmars-d-learn]

On Saturday, 2 September 2017 at 20:03:48 UTC, Jean-Louis Leroy 
wrote:
> So I have:
>
> jll at ORAC:~/dev/d/tests/modules$ tree
> .
> ├── foo
> │   └── bar.d
> └── foo.d
>
> foo.d contains:
> import foo.bar;
>
> bar.d is empty.

This means bar.d's module name will be inferred by the compiler 
[1], which will ignore the path you put it under, yielding the 
module name "bar", not "foo.bar" (one of the issues of doing 
otherwise would be how the compiler should know at which path 
depth the inference should start - and any solution to that other 
than simply ignoring the path would be full of special cases):

>> Modules have a one-to-one correspondence with source files. 
>> The module name is, by default, the file name with the path 
>> and extension stripped off, and can be set explicitly with the 
>> module declaration.

>
> Now I try compiling:
> jll at ORAC:~/dev/d/tests/modules$ dmd -c foo.d

This looks like a compiler bug to me (accepts invalid), though 
I'm not certain.

> jll at ORAC:~/dev/d/tests/modules$ dmd -c foo/bar.d

(No issue here, just an empty module being compiled separately)

>
> So far so good. Now I try it the way dub does it:
> jll at ORAC:~/dev/d/tests/modules$ dmd -c foo.d foo/bar.d
> foo.d(1): Error: module bar from file foo/bar.d must be 
> imported with 'import bar;'
>
> What's up?

This doesn't work, because of the inferred module name for 
foo/bar.d being "bar".
So the compiler wants you to import it by the name it has 
inferred for you (The fix being either specifying the module name 
in foo/bar.d as `module foo.bar`, or importing it as via `import 
bar;` in foo.d).
[1] https://dlang.org/spec/module.html