Phobos 3 Discussion Notes - 02-01-2024

[Adam Wilson]

On Friday, 2 February 2024 at 21:11:51 UTC, Andrea Fontana wrote:
> 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;

This hasn't been fully decided yet, and I probably need to have a 
chat with Atila so we can sort out some of the practical issues. 
But what I am pushing for is tying Phobos versions to matching 
editions. Example: Phobos 3 == Edition 2025 (2024?), Phobos 4 == 
Edition 2026, etc. The plan as I understand it is that Phobos 3 
code can be built with later editions. So the "Edition 2025" is a 
minimum supported edition level.

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

I've heard rumors about going mono-repo. But for the moment they 
are in separate repos, and the initial Phobos 3 development will 
likely be done in a separate repo to avoid waiting on and 
conflicting with the primary development path. After that I would 
expect it to land in the same repo as Phobos 2.

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

Easier said that done, because the one thing you cannot do 
without an external library is cryptography, and if the advice is 
to just use OpenSSL, we would be better served telling them to 
skip that entirely and just check themselves into a mental 
institution directly (I implemented crypto using OpenSSL, AMA).

Specific to libcurl I think we should use the built-in sockets, 
but this requires a bunch of work from JMD, who is also heading 
up ranges. We have a lot of work and few people to help, so we 
have to be judicious here, and C libraries via ImportC offer an 
appealing amount of leverage.

> - Phobos with webassembly

This is mostly a DMD/DRT problem. The big hang-up with WASM has 
been that WASM only recently got GC support and the current 
compiler integrations haven't been updated to support, it you 
want to help out with that, look for a call for volunteers from 
Mike Parker some time in the near future. WASM is pretty high up 
the priority list.

> - Phobos with betterC

This is not in the cards. BetterC would seriously constrain the 
capability of Phobos as we expect to support TypeInfo/ModuleInfo, 
threading, Dynamic/Associative arrays, and static module 
constructors/destructors.

> Andrea