I was perusing a PR for phobos where std/range.d was split into submodules and std/range.d was moved to std/range/package.d

I was wondering why a package module had to be called "package.d" instead of just being the package name.  For example, instead of moving std/range.d to std/range/package.d, why doesn't modifying std/range.d to contain the public imports of the submodules work just as well?

My first thought was that maybe it let's the compiler know that all "package" modifiers are visible to all the modules in the same package, and the only way the compiler knows about what modules are in a package are if they are imported in the package.d file...is this one of the reasons?  Also are there other reasons?  Thanks in advance.

On Monday, 10 November 2014 at 21:25:32 UTC, Jonathan Marler wrote:
> I was perusing a PR for phobos where std/range.d was split into submodules and std/range.d was moved to std/range/package.d
>
> I was wondering why a package module had to be called "package.d" instead of just being the package name.  For example, instead of moving std/range.d to std/range/package.d, why doesn't modifying std/range.d to contain the public imports of the submodules work just as well?
>
> My first thought was that maybe it let's the compiler know that all "package" modifiers are visible to all the modules in the same package, and the only way the compiler knows about what modules are in a package are if they are imported in the package.d file...is this one of the reasons?  Also are there other reasons?  Thanks in advance.

You can't have both module and package of the same name AFAIR. Thus std/range.d + std/range/something.d simply won't work

On 11/10/14 4:33 PM, Dicebot wrote:
> On Monday, 10 November 2014 at 21:25:32 UTC, Jonathan Marler wrote:
>> I was perusing a PR for phobos where std/range.d was split into
>> submodules and std/range.d was moved to std/range/package.d
>>
>> I was wondering why a package module had to be called "package.d"
>> instead of just being the package name.  For example, instead of
>> moving std/range.d to std/range/package.d, why doesn't modifying
>> std/range.d to contain the public imports of the submodules work just
>> as well?
>>
>> My first thought was that maybe it let's the compiler know that all
>> "package" modifiers are visible to all the modules in the same
>> package, and the only way the compiler knows about what modules are in
>> a package are if they are imported in the package.d file...is this one
>> of the reasons?  Also are there other reasons?  Thanks in advance.
>
> You can't have both module and package of the same name AFAIR. Thus
> std/range.d + std/range/something.d simply won't work

I don't think this is it, although that was the rule, we could easily have allowed it.

I think the reasons package.d were chosen are:
1. Logically, you want all to be within the same "package", and std/range.d is in a different package from std/range/x.d
2. package is a keyword, and cannot be a module name

Incidentally, allowing this idiom gives new life to the "package" keyword :)

-Steve