Walter and I had a productive conversation yesterday about Phobos 3 and we felt it would be appropriate to share some notes on our discussion.

The conversation started out with me fumbling around trying to understand how Editions are going to effect Phobos. The discussion settled around two topics.

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.

The other major topic of discussion was what I've been calling the "Crippled by Default" design of editions, where the oldest edition (technically the last pre-edition release) is the default edition if no edition is specified. This poses a few challenges from an end-user standpoint, but the argument that ended up resonating was the idea that in engineering we always want to make the "right" way the default or easiest way to do something, and then provide escape hatches where necessary.

Therefore, the compiler should default to use the latest version and then provide the ability via a switch to set the edition, or lack thereof, of the modules an import path. This solves the problem of abandon-ware packages being accessible without presenting the new user with an ever more decayed version of the compiler. We want to put out best foot forward and presenting the last pre-editions release, which is constantly getting old as time passes, does not do that. No specific agreement was reached but Walter agreed to consider it.

When then moved on to a conversation about how Walter envisions editions actually working. Since none of have seen the document that Atila is working on, Walter shared his opinions on how it should work. Essentially, Walter would like to see a "hybrid" approach having edition attributes for specific experimental features, and then having a yearly "roll-up" edition that includes all the promoted features from the prior year. So if DIP1000 gets promoted to Edition 2025, then DIP1000 would be active by default in that edition and all subsequent editions without having to specifically enable it.

I did bring up that this was likely to cause another "function attribute soup" problem, but in general I wholeheartedly agree with the idea that editions should use this model, both C# and C++ both do something similar so it would be conceptually comfortable to users coming from those languages. Atila, if you're reading this, this is what Walter was thinking/hoping would appear, but since we don't have your document we were mostly left to speculate. We await your document drop with anticipation!

After that we had a discussion about how to distribute Phobos. This mostly centered on what release cadence to use. I argued for linking the Phobos version to the edition release schedule. I think this is sensible and makes it easier for people to reason about which compiler/library pairing they are using. Walter was fine with that, but he does not want to use the "Edition" language to describe Phobos releases. I think this makes sense as Phobos doesn't really have editions, but following SemVer, it would have yearly major releases. This would mean that new features are released once per year, and bugfixes would be released on whatever the fast-cadence schedule is for DMD in between Yearly Edition roll-ups.

Finally, we touched briefly on the major changes we would like to see in Phobos 3 and these are the major changes we are committing to for Phobos 3 so far:

• Removal of Autodecoding.
• Promoting allocators out of experimental.
• Range interface redesign (see JMD's thread here).
• Fix std.traits.

The above list is not exhaustive and we are open to further suggestions. For myself, I would love to see Cryptography and Stream API's make it into Phobos, but I am sure that the list of what the community wants to add is legion so those could end up being lower priority.

One thing I would like to arrange if possible is planning sessions with the people involved with that specific change streamed to YouTube so that the community can participate via the Discord. If a person wishes to join the stream for a face-to-face discussion we would make the link available via DM. I found this discussion with Walter to be a much more efficient use of time and far more agreeable than writing long posts on the NG (the irony given the length of this post... I know).

If you would like to participate in the design discussion on Phobos 3, I am currently hosting a repo on my GitHub with GH Discussions for unresolved/undesigned topics, and PR's for editing the actual design document. Link is here: https://github.com/LightBender/PhobosV3-Design

On Friday, 2 February 2024 at 09:09:37 UTC, Adam Wilson wrote:

What about the missing standard library pieces that are core to everyday software dev? Stuff you get out of the box with java/python. Is there such considerations beyond fixing the mistakes of v2?

• Json
• XML
• Streams
• Networking (http, socket, ...)
  ....

If I understand correctly, v3 is about . How about new module additions to v3 such as the above?

On Friday, 2 February 2024 at 14:46:45 UTC, aberba wrote:

The above list are all things that I would love to see make it in to Phobos 3. The reason that I haven't put them down as commitments is because, as Rikki noted, the present design does not yet allow us to make those commitments yet. The multi-root design I've proposed would allow us to deliver them without breaking Windows, but my campaign to get it accepted hasn't been approved yet.

And you did hit on an important point though, the things that we are looking at adding are cross-cutting concerns that are applicable to a wide variety of software and that's the guideline we're going to follow moving forward.

On Friday, 2 February 2024 at 09:09:37 UTC, Adam Wilson wrote:

Why isn't Atila's document stored in a respository or shared drive somewhere that Walter has read access to? I understand not wanting to release it to the public before it's ready, but the fact that even the two leaders of the D project are forced to guess what the other is working on is completely ridiculous.

The good news is that this is a really easy problem to solve. If setting up a private Github repository and pushing to it is too much effort, even something as simple as using Google docs would work.

Great to see. Is there a plan to update this repository and/or its Discussions page to reflect the material covered in this post? If not, how can I volunteer to help make that happen?

On Friday, 2 February 2024 at 14:46:45 UTC, aberba wrote:

A better solution would be something like this:

dub dxml;

void main() {
  // Call functions from the dxml package
}

The compiler would know about certain popular packages on code.dlang.org. It would download the package if needed, and it would know where to find the relevant files.

There are good reasons to not add that stuff to Phobos. The standard to get something in Phobos is high enough that it leads to a lot of wasted time for many people, it doesn't bloat the compiler download size, it takes advantage of work that's already been done, and it could be done quickly, rather than the years it takes to get stuff done otherwise. (I'm writing this fully aware of how things get done around here, but I'm going to put it out there anyway.)

Concerning allocators, needs a simpler API in core.memory, without assumptions and without typeinfo, so libraries can depend on it from bare metal to higher level desktop applications, i dream of a way to change the associated array's allocator for a custom one for example

The one in std.experimental is too over engineered to depend on it

Concerning std.traits is this package really needed? perhaps work should go in improving __traits instead?

I agree with aberba, i view the STD as building blocks for your program, instead of just utility functions, std.net std.event std.container std.database etc

Hence i view the "fix std.traits` a waste of time, at least for a Phobos 3 work

To me Phobos 3 should be an opportunity to make D's std competitive with other language's std, std.net shouldn't be a binding to curl for example, and if that's not in phobos 3's goals, then what's the point? Too many people asking how to ship with curl on windows.. that shouldn't be a problem when someone is using the language's std, it should just work

On Friday, 2 February 2024 at 16:46:08 UTC, Paul Backus wrote:

Probably because reaching for GitHub is not how people think-by-default when thinking about a document. I only stumbled to it because Walter sent me a markdown document for his Phobos 3 ideas and that randomly triggered the connection in my head. I agree that the present situation is less than ideal, but it's what we've got to work with.

I merged two of the open PRs on the document last night based on the discussion. I have one more to do (DUB Only Builds) but I ran out of steam and needed to get some sleep. There is a discussion open on Versioned Roots, but I talked Walter out of that, so I will post updates there and I have opened a PR to my proposed multi-root design here: https://github.com/LightBender/PhobosV3-Design/pull/3 but I need to update it on the basis of the discussion. Time is, as always, in short supply.

If you have ideas about the general design that aren't fully formed or need to debated please open up a new Discussion (if I need some form of access let me know, this is my first time using Discussions). If you have a specific change proposal to the document please open up a PR and we'll discuss it in the Review comments.