Phobos 3 Discussion Notes - 02-01-2024

[Atila Neves]

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

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

And then subsequent versions get put in a package with a version 
number under that?

> 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

Which ones?

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

And the right way should be to not break existing code, even if 
they upgrade the compiler.

> Therefore, the compiler should default to use the latest version

The latest version of Phobos? Of the language?

> and then provide the ability via a switch to set the edition, 
> or lack thereof, of the modules an import path.

I think this option is useful for trying to upgrade a project to 
a new edition, but I'm not sure how it applies here.

> This solves the problem of abandon-ware packages being 
> accessible

Abandon-ware Phobos packages?

> without presenting the new user with an ever more decayed 
> version of the compiler.

I don't understand what this means.

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

It's unclear to me how we'd be doing that if the new Phobos 
version(s) is namespaced differently.

> 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'm not sure every year is a good time interval.

> I did bring up that this was likely to cause another "function 
> attribute soup" problem

How?

> 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,

The reason for that is because I told him that's how I was 
thinking of doing it ;)

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

This is the part I'm really not clear about yet.

> I think this makes sense as Phobos doesn't really have editions,

Unless it opts in to a new one. And it should, because we want to 
lead by example.

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

This requires solving a number of thorny issues, including "does 
this API even make sense?", which I'm told Paul Backus is working 
on.

> - Range interface redesign (see JMD's thread 
> [here](https://forum.dlang.org/thread/mailman.588.1705813271.3719.digitalmars-d@puremagic.com)).
> - Fix std.traits.

What does "fix" mean in this context?

> The above list is not exhaustive and we are open to further 
> suggestions.

- XML
- JSON
- YAML
- SDL?
- Channels
- ...