On Friday, 4 November 2022 at 19:34:58 UTC, jmh530 wrote:

It was originally added because Phobos had std.algorithm and std.datetime and some people wanted to break them up into pieces, but not break user code that still said import std.algorithm instead of import std.algorithm.sorting (or whatever).

One alternative was to call the new things like std.algorithm_parts.sorted but this name a little ugly and people would be less likely to transition to it.

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 use that feature a lot, just search with the folder name, then "package"

https://i.imgur.com/cHb7isl.png

it's also very useful to avoid having all of your code in a giant unreadable single file

it's also very useful to avoid using dub.. just an import path to the folder and that's it

https://i.imgur.com/Wy6WOXK.png

also very useful when you want to simplify using importc, put your c files under the c folder, and the package.d, public import the c files, and you can put some helper code in D there, very nice to have

On Saturday, 5 November 2022 at 01:34:04 UTC, ryuukk_ wrote:

I believe that needing to write package.d manually is pretty useless. Most of the time it means "import everything from this directory". The only real usage that helped me is when I needed to create a version(Release) import something.opt; else version(Debug) import something.hotload; basically.

But that does not really require package.d.
Those historic issues that Adam said are the real cause of their current design.

Take into account how would you do it in Java. import mypackage.*; is how it was done, and I haven't never had any problem doing this, and this is pretty descriptive.

package.d feels a lot more Haxe's import.hx, but it has a main difference that import.hx is a REAL special file that changes a bit on what happens on your source files. They are automatically included in its dir/subdir (think of a per directory object.d).

The problem is that I'm not saying package.d is worthless, but it is a pool of bugs in the language that needs a real fix and only that post has already showed 4 bugs people have had. (Although I still don't like searching files by package.d, it is counter intuitive).

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.

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!