Why is Phobos organized the way it is?

[nairboon]

Since this group seems to know D very well, I want to ask this question here:
What is the hidden logic in the organization of the standard library?
If you have used D for a long time, I guess all of this is in your muscle memory, but from the outside the following seems to be a bit weird:

• Why is std.complex not in std.math?
• Why std.ascii, std.utf, std.base64 not in std.encoding?
• curl is in std.net, but socket and uri is toplevel?
• std.array and std.container.array... why?
• std.zip and std.zlib are toplevel, why stop there and not have std.bzip, std.brotli, std.gz, std.xz, ... ?
• std.csv and std.json are topleve, why stop there and not have std.xls, std.parquet, std.xml, ...?

While some of this list is a bit sarcastic, I hope you get my overall point.
I guess some of it is historical, to reduce typing, but as the stdlib grows, it becomes difficult to find stuff, because you have to look everywhere.

Does anyone know the overall organization principles of this stdlib? Why was this never cleaned up?

[andrey-zherikov]

IMO the reason why it doesn't grow is that there is no clear process of how to add new modules into it.

[nairboon]

One could adopt the working processes from Python like PEP 2 – Procedure for Adding New Modules

[adamdruppe]

Why is std.complex not in std.math?

just historical, there was already a std.math and complex was built into the language, then it came out but didn't want to step on the existing module but still be up top due to previously being a lang feature

Why std.ascii, std.utf, std.base64 not in std.encoding?

std.encoding is about text encoding so base64 i don't think would fit but the others just historical again i think, std.ascii has been there for ages.

curl is in std.net, but socket and uri is toplevel?

socket and uri are technically more than net but again they just been there forever so historical.

std.array and std.container.array... why?

std.array works with the built in language arrays and container.array replaces it.

std.zip and std.zlib are toplevel, why stop there and not have std.bzip, std.brotli, std.gz, std.xz, ... ?

zlib is gz fyi.

but arsd has many of those! OpenD will soon include the arsd libs too.

std.csv and std.json are topleve, why stop there and not have std.xls, std.parquet, std.xml, ...?

There used to be std.xml but they removed it. But again, arsd has many of these, so opend does too!

If you want to search things you can use my dpldocs.info search engine

[quickfur]

We should lay down some rules on adding stuff to phobos. Just so everyone is clear what's expected to add a new module.

And while we're at it, since openD hasn't made a release yet, now's a good time to do any fundamental reorgs of std.*. For compatibility with code ported from upstream, we should leave stub public imports in the old paths so that old code will still compile without a problem, but new code should be written to the new structure.

[adamdruppe]

Yeah they've been talking about a new phobos version for a long time. People have tried to work toward it just to be shut down by contradictory requirements from on high. So while I kinda want to reserve the std.* name for them to do whatever and we can pull it for compatibility I don't expect much to actually come from it upstream.

For here, I'm thinking the real functionality comes from recommended bundled libraries. There's still space for an interop thing though..

so if the core namespace is reserved for druntime and the std namespace is reserved for upstream legacy compatibility (tbh i'd prefer to really de-emphasize it since the name "std" implies something it really isn't)... what names would we use for the common, recommended base here?

That's two ideas: common.* for the shared interfaces you use for interop and then perhaps recommended.* for stable libs officially recommended...

[quickfur]

I hate spuriously long identifiers. What about usr.* for shared interfaces and rec.* for recommended stuff? I was going to suggest com.* for common stuff but that risks giving the wrong impression of association with Java's com.* namespace.

[IgorDeepakM]

How about odc.* for "OpenD Common" and odr.* for "OpenD Recommended"?

odr.* might be too visually close to odc.*, so it can be a bit longer like odrec.*

[nairboon]

d.* and d.lib* for recommended libraries would also keep the typing short.

[ttkciar]

Was thinking "dlib" but nairboon's suggestion is better, IMO.

[ttkciar]

There are some great suggestions posed here. They just need to be coalesced into a coherent plan and executed upon.

Suggested plan:

• Adopt PEP2 process for now, see how we like it.

• Keep phobos/std/* as-is (for now) for compatibility with third-party D modules.

• Create subdirectory phobos/d/ (per nairboon's suggestion)

• Copy (some? all?) libraries from phobos/std/* into phobos/d/* in a new hierarchy which makes sense

• Divergence from D's phobos libraries would be implemented in phobos/d/*

• Third-party libraries will be ported to phobos/d/*

Yea? Nay? Rude noises?

[adamdruppe]

That's not bad. My plan for third party libs is to incorporate them right into the release as-is for now but there's controversy on that vs package managers. my pr.... im not sure yet.