Reason for mypackage/package.d instead of mypackage.d

[Steven Schveighoffer via Digitalmars-d-learn]

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