On Thursday, 20 June 2013 at 07:59:57 UTC, Jonathan M Davis wrote:
The _only_ reason that we added package.d was to allow us to
split up modules
in place without breaking existing code. And it works as well
as it does,
because the _only_ new feature that it provides is making it so
that when you
import a package, you import package.d. All other aspects about
it were
already part of the language, and we weren't looking to add any
new
functionality whatsoever beyond being able to break up modules
like
std.algorithm or std.datetime. Trying to treat a package as if
it were a
module because it has a package.d file is contorting things
considerably. That
was never the intention of package.d at all. It's to help us
evolve code
without breaking public APIs. package is not part of the public
API. private
is not part of the public API. As such, they have _nothing_ to
do with the
purpose of package.d. And it was never intended that packages
be treated as
modules due to the presence of package.d save for the purpose
of avoiding code
breakage. IMHO, you are trying to take this _way_ too far.
- Jonathan M Davis
Ok. Then this feature is not really about being able to easily
break an existing module into a package, but rather about
providing a different way to organize your code from the get-go.
You _can_ break existing modules into packages, but you may need
to go through some hoops to do so, and that's fine, because
that's not the primary purpose of this feature anyway.
I'd say let's keep the package access specifier as it is now.
