Is package.d a good idea?

[Steven Schveighoffer]

On 7/4/18 11:29 AM, Jonathan M Davis wrote:
> On Wednesday, July 04, 2018 11:13:07 Steven Schveighoffer via Digitalmars-d
> wrote:
>> I think if we went the different route we would have to provide a
>> mechanism to declare inside the module "this is a package". Maybe
>> "package module"?
> 
> I would point out that the pretty much the only reason that we were able to
> convince Walter to have package.d in the language was because of how
> straightforward it is and how it changed nothing about import semantics and
> required very little to add it. Any other approaches would likely need to
> provide a significant benefit over what we have now in order to be
> acceptable. And suggestions like this just seem to be shuffling things
> around without really changing or improving what you can do.
> 

I'm fully in agreement with you. I just wanted to point out that it's 
not as cut-and-dry as people have been saying -- we would need some new 
mechanism to replicate the current behavior.

The obvious pros to ditching package.d and using a directory and module 
with the same name are: 1. no ambiguity in the filesystem (assuming you 
don't have weird package/file schemes) and 2. It's more understandable 
to someone not used to the current state of affairs.

To me, it's not worth it for just those things. I'm curious why Rust is 
changing.

-Steve