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
