• Jonathan Marler (13/13) Nov 10 2014 I was perusing a PR for phobos where std/range.d was split into
• Dicebot (4/17) Nov 10 2014 You can't have both module and package of the same name AFAIR.
• Steven Schveighoffer (9/26) Nov 10 2014 I don't think this is it, although that was the rule, we could easily

"Jonathan Marler" <johnnymarler gmail.com> writes:

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.

"Dicebot" <public dicebot.lv> writes:

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

Steven Schveighoffer <schveiguy yahoo.com> writes:

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