Package.d is a real problem existing on our currently modules design. First is that it means to take the directory name to use as a module.

This is a problem for 3 reasons:

1. You won't be able to find your module by the file name. This is incredibly common, for instance, in Visual Studio Code, when you hit CTRL+P and type the file name, nope, you will need to write path/to/folder/package.d, beyond that, when you search package.d there will be so many files with the same name.

2. As being an exception to how the module system works, this has already caused me a few headaches (inexplicable bugs), that happens with symbols aliasing, when the time it happened, I had no idea on what it could be and I don't even remember how I solved, instead, I only knew it was related to package.d.

3. I'm currently having a bug on my API module that every duplicated file name, even when located at different directories(modules), are generating duplicate symbol. The major problem is that this is currently undebuggable, as the MSVC Linker does not show the full directory of the libraries/object files that caused this clash, not even the symbol!

The duplicate symbol currently only happens in MSVC Linker, which makes me think if the bug is in the D language or the linker itself, as on LLD this does not happen.
So, my current advice is always try making your file names unique, this will bring a much better debuggability in your project.

On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:

I disagree completely with being against package.d.

Having used D for like a decade at this point, I've never experienced any issues with it.

Most issues seems to be for newcomers and people who aren't entirely familiar with how D modules and packages work.

package.d is absolutely essential in some cases.

On Friday, 4 November 2022 at 14:11:55 UTC, bauss wrote:

Literally my linker error disappeared after I changed it to another name.
And I can't see how essential package.d is, there's no D difference in the code written.

As it being the exception inside our compiler, it is an entire pool for bugs to get wild out there.

On Friday, 4 November 2022 at 10:57:12 UTC, Hipreme wrote:

What do we use instead?
I won't lie about the fact package.d forced me to workaround elusive "bugs" in my usage(1) but what is the alternative if we don't want to work around it?

(1)(ime : had cases of package.d requiring compiler specific pragmas for LDC, and dub can't find the package's source files at all if it's a multi file subpackage intended to be imported only, i never got it working with package.d, only a single source file setup *packagename*.d would work...)

On Friday, 4 November 2022 at 16:21:17 UTC, z wrote:

You can use any name instead. The only difference between an ordinary source file and a package.d is the module name. For instance, if you're inside the filesystem directory, you can change the name to literally anything and import instead. To make my engine's names unique I have been using a convention for the package.d names as an abbreviation of the directory name plus definitions or something like that.

On Friday, 4 November 2022 at 16:56:59 UTC, Hipreme wrote:

If you don't plan to use private(package_name), then I don't know what the point of it is.