The first PR for Phobos 3 has been merged into the Phobos repo!

Now, to be clear, this is mostly a housekeeping PR that paves the way for further work and there isn't actually anything useful in it yet. We've setup the basic structure, DUB build/test config, and copied over the modules that don't have any std imports. The next project will be to (slowly) audit each file for any trace of auto-decoding. No module can be added to V3 without first being cleared of auto-decoding.

With this comes a few changes in the development process for Phobos. The first of which is that all changes to Phobos will now need to be cross-applied to both libraries. We have kept V3 in the same repo as V2 to make this process easier, but you will need to check the V3 directory (tentatively labeled lib) to see if the V2 file you're modifying is included in V3 yet, and if it is, please include your change in corresponding V3 file as well. This will be enforced during the review process. If you are unsure, you can ping me on GitHub as @LightBender in your PR and I'll take a look. As we progress, I am sure that the other reviewers will become familiar with the state of the V3 code-base.

Note that this process will continue for the indefinite future as we intended to maintain V2 alongside V3+. While the exact level of support that V2 will receive once V3 is launched hasn't been fulled resolved, at a minimum, it must remain in a buildable state indefinitely.

Another note is that I do have a day job, so I will only be working on V3 in my spare time, as such, any help with the auto-decoding audit would be immensely appreciated as that will significantly speed up the time to completion and let us start focusing on the projects we all want to see happen in Phobos.

If you have any V3 specific questions or comments you can join the discussion that's happening in this GitHub repo: https://github.com/LightBender/PhobosV3-Design
Or, you can ask on the Forums and in the Discord and I'll do my best to keep up with the updates in those places.

Finally, I would like to thank everybody who has contributed to the design of V3 already (there are too many to list, you know who you are), you've been a wonderful help as we start this journey. Thanks to your efforts the future of Phobos is looking very bright!

https://github.com/dlang/phobos/pull/8925/files#diff-647aa2ce9ebedd6759a2f1c55752f0279de8ae7ba55e3c270bd59e1f8c1a5162R131

Why can't D have its own types?

Just importing this introduces dependencies on other system modules

import core.stdc.config;
import core.stdc.stddef; // for wchar_t
import core.stdc.signal; // for sig_atomic_t
import core.stdc.wchar_; // for wint_t

Wich makes phobos harder to use on platforms without these

I think Phobos as a base shouldn't depend on libc, only specific parts eg: network/event modules for example, so it becomes easier to port when required

On Wednesday, 28 February 2024 at 15:45:06 UTC, ryuukk_ wrote:

I have to agree with ryuukk_ on this one; it's one thing to maintain binary compatibility with C, and another to import and use C symbols all over the place in the standard library. I think that interfaces with C (or any other language) should be reduced to the minimum required to make something work, and nothing more. So, keep the usage of malloc/realloc/free to allocators and whatnot, and use fread/fwrite only in stdio.

On Wednesday, 28 February 2024 at 15:55:52 UTC, Andrew wrote:

Absolutely agreed, I’d love to use Phobos in code targeting smaller platforms that is not just desktop Linux, macOS, windows or Bsd. Also being able to use smaller libc(s) where a full glibc is not available would be really nice.

On Wednesday, 28 February 2024 at 19:45:53 UTC, Greggor wrote:

I am totally on board with this if the community thinks there are improvements to be had here. Head on over to the Design repo and you can either submit a PR to the design document, or start a discussion if there is disagreement on how to handle this.

On Wednesday, 28 February 2024 at 20:41:46 UTC, Adam Wilson wrote:

Although Github has discussions, why not just discuss them in the D forum? This is the forum. Github doesn't have the convenience of the D forum at all. Why bother with them?

On Wednesday, 28 February 2024 at 20:41:46 UTC, Adam Wilson wrote:

I'll see if I can check it out next weekend, if that's not too late. Studying for my private pilot exam takes priority sadly.

On Wednesday, 28 February 2024 at 15:45:06 UTC, ryuukk_ wrote:

import core.stdc.config;
import core.stdc.stddef; // for wchar_t
import core.stdc.signal; // for sig_atomic_t
import core.stdc.wchar_; // for wint_t

+1

My current setup in wasm has a broken libc and that makes most the std useless unleast I want to go wack a mole in the depths of core.math

On Thursday, 29 February 2024 at 13:44:37 UTC, Andrew wrote:

As a fellow pilot, I agree with this prioritization.

On Thursday, 29 February 2024 at 00:34:59 UTC, zjh wrote:

A couple of reasons.
First it's easier to cross-tab discussions with work on the design docs.
Second, we started this during the whole fork and didn't need that bleeding into the discussion.
Third, we didn't know how this will this GH experiment would work but we wanted to try it out. So far it's been a smashing success.