Package Name for Phobos V3

[pbackus]

From the forum:

The first was how to construct the package structure for Phobos 3. Walter has proposed using std2. as the root namespace. His primary reason was that he wanted to avoid the potential for importing anything from std. that might trigger auto-decoding. I pointed out two major flaws with this design.

First, it would be very easy to accidentally type std. in an std2. module. We realized that this would be a problem no matter what root name was used and that the appropriate answer would be to specify a DStyle rule specific to Phobos that only modules in std. can import std. modules.

Second, this design implies that the '2' in std2. is a version specifier that would be incremented with each Phobos release. This was not the intention and we agreed that it would be confusing. I proposed using sys. as the root name for Phobos 3 and Walter found that acceptable. We briefly discussed splitting up Phobos into multiple roots and no firm agreement was reached.

[pbackus]

Currently, we use the package name sys in core.sys with the meaning of "something specific to a particular target platform." Since Phobos is supposed to provide portable, non-platform-dependent interfaces, using sys for Phobos as well could lead to confusion.

[LightBender]

This is an interesting point. I was basing it off the need to name it something other than std and not std3 since we're explicitly trying not to imply that the version is baked into the root. I used sys because it's short hand for "system" and my C# background is bleeding through, but I can come up with some synonyms that we could try to cut down to three letters.

[pbackus]

I don't see why it's necessary for the name to be 3 letters. Seems needlessly restrictive.

Some other possibilities:

• dlang (like Java's java package)
• phobos
• lib

[LightBender]

Because some people here have a thing about typing out characters? I dunno, I'm pandering I suppose, but personally, I'm used to typing out things like System.Text.Json.Serialization; so all of the above are fine by me!
My preference would be either for lib or phobos.

[pbackus]

Also, on POSIX, there is a sys directory in the default #include path which includes headers like sys/stat.h and sys/ioctl.h. If ImportC ever gains the ability to import headers, these headers will appear in the sys package, creating a namespace collision with Phobos.

[maxhaton]

What do you mean by include? It already does preprocessing

[LightBender]

It calls out to the system preprocessor right now. Which I suppose it could continue to do, but in direct compiler invocations it would ruin build times if you didn't build your own preprocessor into the importer. People have been asking for direct C header imports from D and @WalterBright is (rightly IMO) pushing back on that. I really don't understand why people want to run an import on what should be a static .h file with every build invocation. Run the import once to generate a .DI file and import that. Much cleaner, much faster.

[pbackus]

If the intended usage is to generate a .di file in a separate build step, and then import that, why do we even need the ability to import C files directly in the first place?

[maxhaton]

Ruining build times via preprocessing would be harder than you'd think. I know this code quite well (I wrote the what Walter adapted to become the original one in dmd), preprocessing isn't particularly expensive, especially if you cache it.

Also, mimicking the system preprocessor is extremely non-trivial. The code won't be that big, but it's millions of dollars of work to mimic the exact behaviour/builtins of (say) GCC — this is afaict what killed walters warp thing at facebook, that and clang was faster anyway. Would be a complete mistake to invest time in unless as a last resort for (say) a windows installation with no toolchain.

And yes @pbackus it does seem odd — dstep anyone? At least 2 other tools are available.

[LightBender]

@pbackus That wasn't the intent, it was a happy accident that Walter wasn't even aware was possible until we showed it too him. That's it's become the default way of using ImportC is more due to the fact that the tooling works better with the .di file as Code-D cannot read the directly imported C file. Sometimes unintended usage patterns emerge, it's the nature of large systems.

@maxhaton For whatever reason those tools haven't caught on like ImportC has, maybe they are more difficult to work with, maybe what they produce isn't as clean, maybe the fact that D is also a C compiler but those tools aren't makes the difference; I don't know, but ImportC works best for everything I've tried.

[crazymonkyyy]

import pho;
next editions of std get named after different moons, but 3 letter unix naming since everyone will need to type it

[atilaneves]

Why not std.v3? I like phobos though.

[LightBender]

Ok, here we go.

First: Naming it std3 was never about versioning, it was about getting a new namespace that would make imports to the old auto-decoding version of Phobos obvious. However, this fails on two counts. First, it's very easy to accidentally type out std. instead of std3. and it's not visually distinctive when scanning code. This led to the realization that only a linter rule would solve this. Second, as literally everyone has misinterpreted, yourself included, it implies a version number where none was intended. std3. was intended be with us for all future versions.

Second: This will significantly increase build times. Because even if a module is just a list of public imports, a module must be specified per version. Strictly speaking the build time increases would be exponential with each version. Example:

std.v5.stdio

std.v4.stdio

std.v3.stdio

Each file must exist and must be read and compiled. And no. Asking programmers to "remember" which version has the active file is not an answer, it's an aggravation that no programmer will suffer long.

Third: It's a maintenance nightmare. Missing public import modules. Code for one "module" scattered all over the folder structure. Version are best handled at the version control level.

Fourth: Name one other major language that does it this way? It will be extremely confusing and off-putting for the legions of programmers potentially coming from other languages like C++/C#/Java that have never seen anything like this. Being different for the sake of "being different" is never a good idea.

[atilaneves]

Ok. Then I don't think std3 is a good name.

I don't understand the point about build times. Or the oneo about maintenance.

I agree that being different for the sake of it is a bad idea.

[crazymonkyyy]

doing whatever, starting yeasterday
its been months and you haven't yet named a folder

[LightBender]

I have long since learned that looking before you leap is always a good idea. Wasting effort on something that has a high chance of getting thrown out because we didn't thoroughly evaluate what we needed to do to get it done correctly is even more aggravating than simply not starting.

Will stuff happen, sure, but without some buy-in before getting started, I'd just be wasting my time. And remember, because it's not your time, you don't value it as highly. Me on the other-hand, I'm positively buried in work that's not DLF related, and most of what I am doing right now is lobbying for sanity before I decided to take the plunge and start invest large amounts of time.

[crazymonkyyy]

Its a folder name, I dont understand how its hard to change or findreplace "import std.v2" with "import pho"

The thing that matters is the range api and coordinating my wishlist, with the immutable wishlist, sink/source wishlist, simplicity, sane renaming and whatever complexity's come out from actually having data structures and I think you should maximize time thats in the oven with example code seeing what breaks.

[SRKX0A]

If there's no 3 letter restriction, I think that phobos is clearly the best choice. A little weird, but that's the name of the library, and is totally unambiguous. pho is an okay 3-letter one though. Something about this being one of the only two hard things in computer science...

[Moth-Tolias]

dlang, lib, and phobos are all good names. I would be happy with any of them.

[thewilsonator]

In the process of editions, if when mangling, packages encode the edition, then we avoid the need to choose a new name.

Also we should at least look at C++11 as a point of comparison, i.e. what does a module analogue of an inline namespace look like.

[LightBender]

While that might be possible, and is likely where we end up with later Phobos versions, there are a couple of reasons to do it this way. One is that getting rid of auto-decoding requires that we do this as a separate package. @schveiguy tried to do it inside the existing std root and it was painfully disruptive for both the him as the engineer doing the work and the users. Andrei eventually killed the whole idea.
The second is that we want to keep the original Phobos 2 alive as-is, which means we have to put the new Phobos somewhere else.

[thewilsonator]

there is nothing that precludes different editions from being in different packages, and assuming you tie an edition to a dub configuration, that is an easy thing to do.

[ichordev]

Surprised nobody suggested dsl yet? (for 'D Standard Library')
But I also think that just d works perfectly well:

import d.algorithm.iteration;
import d.container.binaryheap;

[Moth-Tolias]

dsl has numerous other expansions and could become confusing.
I quite like the idea of d though.

[LightBender]

This has been resolved with the phobos. package name being selected by the DLF. I liked lib. but the DLF owns the name so it was their prerogative.