currently when no module declaration is given, the module name is given by
the path base name (__FILE__.baseName.stripExtension).
This is rarely useful (as soon as one has modules nested in packages).
Why not instead infer the module name from the relative path of __FILE__
with respect to the first directory in the import list in which __FILE__ is
found:

---- src/foo/bar.d:
// infers 'module foo.bar;' instead of 'module bar;'
void barfun(){}
----

---- src/main.d:
import foo.bar;
void main(){}
----

dmd -Isrc src/main.d

On Monday, 15 July 2013 at 15:45:47 UTC, Timothee Cour wrote:
> ---- src/foo/bar.d:
> // infers 'module foo.bar;' instead of 'module bar;'
> void barfun(){}
> ----
>
> ---- src/main.d:
> import foo.bar;
> void main(){}
> ----
>
> dmd -Isrc src/main.d

And what if I compile it like this?

dmd -c src/foo/bar.d
dmd -c -Isrc src/main.d
// link later

I don't think this can work in general.

On Mon, Jul 15, 2013 at 9:55 AM, Peter Alexander < peter.alexander.au@gmail.com> wrote:

> On Monday, 15 July 2013 at 15:45:47 UTC, Timothee Cour wrote:
>
>> ---- src/foo/bar.d:
>> // infers 'module foo.bar;' instead of 'module bar;'
>> void barfun(){}
>> ----
>>
>> ---- src/main.d:
>> import foo.bar;
>> void main(){}
>> ----
>>
>> dmd -Isrc src/main.d
>>
>
> And what if I compile it like this?
>
> dmd -c src/foo/bar.d
> dmd -c -Isrc src/main.d
> // link later
>
> I don't think this can work in general.
>

Yes I thought about that case. It would still work by passing the same -I
flags:
dmd -c -Isrc src/foo/bar.d
dmd -c -Isrc src/main.d
// link later

When a file would be fully specified on the command line as above, the -I flag would specify the offset from which to compute the relative path. I think it's a simple rule that makes code more DRY and easy to refactor.

On 2013-07-15 17:45, Timothee Cour wrote:
> currently when no module declaration is given, the module name is given
> by the path base name (__FILE__.baseName.stripExtension).
> This is rarely useful (as soon as one has modules nested in packages).
> Why not instead infer the module name from the relative path of __FILE__
> with respect to the first directory in the import list in which __FILE__
> is found:
>
> ---- src/foo/bar.d:
> // infers 'module foo.bar;' instead of 'module bar;'
> void barfun(){}
> ----
>
> ---- src/main.d:
> import foo.bar;
> void main(){}
> ----
>
> dmd -Isrc src/main.d

Why not just specify a module declaration? I always do that.

-- 
/Jacob Carlborg

On Mon, Jul 15, 2013 at 11:31 AM, Jacob Carlborg <doob@me.com> wrote:

> On 2013-07-15 17:45, Timothee Cour wrote:
>
>> currently when no module declaration is given, the module name is given
>> by the path base name (__FILE__.baseName.**stripExtension).
>> This is rarely useful (as soon as one has modules nested in packages).
>> Why not instead infer the module name from the relative path of __FILE__
>> with respect to the first directory in the import list in which __FILE__
>> is found:
>>
>> ---- src/foo/bar.d:
>> // infers 'module foo.bar;' instead of 'module bar;'
>> void barfun(){}
>> ----
>>
>> ---- src/main.d:
>> import foo.bar;
>> void main(){}
>> ----
>>
>> dmd -Isrc src/main.d
>>
>
> Why not just specify a module declaration? I always do that.


I do so as well precisely because of the current module name inference rule. But with this proposal, it would become optional, making the code more DRY and easier to refactor. Especially useful during development phase.