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