Phobos 3 Discussion Notes - 02-01-2024

Andrea Fontana nospam at example.org
Fri Feb 2 21:11:51 UTC 2024


On Friday, 2 February 2024 at 09:09:37 UTC, Adam Wilson wrote:
> 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.

What about std.v1.*, std.v2.* and so on? And obviously std.v1.* 
== std.*

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

Is the newest compiler compatible with oldest phobos?
Maybe some sort of automagical import std.old.v108;

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

Can phobos and dmd split themselves, just like any other library, 
or are we supposed to keep them together?

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

+1

> - Promoting allocators out of experimental.

+1

> - Range interface redesign

+1

> - Fix std.traits.

+1

- Removing ext dependencies could make things easier (f.e. 
libcurl) for multi-platform development (it's nice to statically 
compile everything in a single executable, but it's not that 
easy: I did it for https://github.com/trikko/tshare)
- Phobos with webassembly
- Phobos with betterC

Andrea




More information about the Digitalmars-d mailing list