Keyword "package" prevents from importing a package module "package.d"

[Adam D Ruppe]

On Friday, 3 November 2023 at 00:19:48 UTC, Andrey Zherikov wrote:
> Is there any guide how one can refactor single-module package 
> into multi-module package with distinction between public and 
> private modules?

Call the modules literally anything else and it works better.

So say you have module foo.bar. You could keep that and put your 
multiple modules in a different thing like foo.bar_parts.part and 
foo.bar_parts.part2. This maintains compatibility on the user 
side; if they were previously using foo.bar, things keep working 
for them.

Or, you could keep everything under foo.bar, but add a 
foo.bar.all that provides the old api. Users would have to adjust 
their imports to say `import foo.bar.all;` instead. This has more 
potential for transition breakage, but it keeps the new modules 
under the old namespace.

I recommend option 1: having the new foo.bar_parts where the 
implementation actually goes. (Or you could call it whatever you 
want.) This avoids the whole package.d thing while still letting 
you and your user arrange modules how you like.

You might also have a thing like `foo.bar_implementation` which 
is not intended for public use.