Phobos 3 Discussion Notes - 02-01-2024

[Adam Wilson]

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](https://forum.dlang.org/thread/mailman.588.1705813271.3719.digitalmars-d@puremagic.com)).
- 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