Also, if we loosen the encapsulation provided by the package access specifier so that it allows access also to modules in nested packages, then why is this keyword even named "package". Newcomers to the language would be asking us why is this keyword names "package", when it provides access beyond the package where the module is in. Loosening the encapsulation provided by 'package' is not logical nor called for.

On Thursday, 20 June 2013 at 05:24:12 UTC, TommiT wrote:
> This is how I see the logic of this new feature you're adding:
>
> When you have a folder named "mod" which contains a file named package.d, the mod folder becomes conceptually a file with same name and the extension "d". I.e. the folder conceptually becomes a module, which you can then import to other modules. All the code contained within all the files contained within the mod folder becomes conceptually the content of this imaginary mod.d file. Therefore it is only logical that all the code within this imaginary mod.d file would have access to 'package'-labeled symbols that are in files which are located under the same folder under which this imaginary mod.d file is.

...and following that thread, I would also argue, that 'private'-labeled symbols in files that are inside this mod folder should be accessible to all the other files that are inside this mod folder, because conceptually all those files are part of the same (imaginary) module (mod.d).

On Thursday, June 20, 2013 08:45:21 TommiT wrote:
> On Thursday, 20 June 2013 at 05:24:12 UTC, TommiT wrote:
> > This is how I see the logic of this new feature you're adding:
> > 
> > When you have a folder named "mod" which contains a file named package.d, the mod folder becomes conceptually a file with same name and the extension "d". I.e. the folder conceptually becomes a module, which you can then import to other modules. All the code contained within all the files contained within the mod folder becomes conceptually the content of this imaginary mod.d file. Therefore it is only logical that all the code within this imaginary mod.d file would have access to 'package'-labeled symbols that are in files which are located under the same folder under which this imaginary mod.d file is.
> 
> ...and following that thread, I would also argue, that 'private'-labeled symbols in files that are inside this mod folder should be accessible to all the other files that are inside this mod folder, because conceptually all those files are part of the same (imaginary) module (mod.d).

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

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.