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.

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,

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,

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:

• 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.

On Saturday, 3 February 2024 at 03:49:54 UTC, Adam Wilson wrote:

Obviously we are not going to get all of Phobos to work with BetterC, but significant chunks of it already do, and there's a good deal more that could be considered low-hanging fruit.

I think the right approach here is to try to make code BetterC-compatible when we can, and to at least keep BetterC compatibility in mind as a "nice-to-have" goal (but not a requirement) when doing API design. For example, if the only thing keeping a function from being BetterC-compatible is that it uses the GC to allocate memory for an error message, it's probably worth a little bit of extra effort to either get rid of that GC dependency, or provide a version (D_BetterC) alternative.

On Saturday, 3 February 2024 at 11:54:48 UTC, ryuukk_ wrote:

The EH problem has two potential answers.

The first is the sumtype answer. That would be zero runtime cost and would achieve a similar result as the current EH scheme.

I think our goal is to make -betterC obsolete. As in: if you don't use the feature, you don't pay for it, and it's implicit.

On Saturday, 3 February 2024 at 12:53:34 UTC, Paul Backus wrote:

I think our goal is to make -betterC obsolete. As in: if you don't use the feature, you don't pay for it, and it's implicit.

On Monday, 5 February 2024 at 14:38:56 UTC, Atila Neves wrote:

This is more of a goal for druntime than Phobos, but yes, agreed.

Even in the 100% pay-as-you-go world, I think we'll still want Phobos APIs to avoid depending on (and paying for) more druntime features than they really need to.

Even in the 100% pay-as-you-go world, I think we'll still want Phobos APIs to avoid depending on (and paying for) more druntime features than they really need to.

On Monday, 5 February 2024 at 15:40:11 UTC, Paul Backus wrote:

This feels delusional to me; like I don't know how the formal style with its contracts and extra asserts and 5 layered datetime will ever avoid rogue imports that aren't part of a blessed compile environment.