www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Phobos 3 Development is Open!

reply Adam Wilson <flyboynw gmail.com> writes:
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!
Feb 28
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
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

```D
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
Feb 28
next sibling parent reply Andrew <andrewlalisofficial gmail.com> writes:
On Wednesday, 28 February 2024 at 15:45:06 UTC, ryuukk_ wrote:

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

 Why can't D have its own types?


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.
Feb 28
parent reply Greggor <not valid.email> writes:
On Wednesday, 28 February 2024 at 15:55:52 UTC, Andrew wrote:

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

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

 Why can't D have its own types?


 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.


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.
Feb 28
parent reply Adam Wilson <flyboynw gmail.com> writes:
On Wednesday, 28 February 2024 at 19:45:53 UTC, Greggor wrote:

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

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

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

 Why can't D have its own types?


 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.


 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.


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.
Feb 28
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Wednesday, 28 February 2024 at 20:41:46 UTC, Adam Wilson wrote:

  or start a discussion if there is disagreement on how to 
 handle this.




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?
Feb 28
parent Adam Wilson <flyboynw gmail.com> writes:
On Thursday, 29 February 2024 at 00:34:59 UTC, zjh wrote:

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

  or start a discussion if there is disagreement on how to 
 handle this.




 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?


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.
Mar 05
prev sibling parent reply Andrew <andrewlalisofficial gmail.com> writes:
On Wednesday, 28 February 2024 at 20:41:46 UTC, Adam Wilson 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.


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.
Feb 29
parent Adam Wilson <flyboynw gmail.com> writes:
On Thursday, 29 February 2024 at 13:44:37 UTC, Andrew wrote:

 On Wednesday, 28 February 2024 at 20:41:46 UTC, Adam Wilson 
 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.


 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.


As a fellow pilot, I agree with this prioritization.
Feb 29
prev sibling parent monkyyy <crazymonkyyy gmail.com> writes:
On Wednesday, 28 February 2024 at 15:45:06 UTC, ryuukk_ wrote:

 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

 ```D
 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


+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
Feb 29
prev sibling parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
On Wednesday, 28 February 2024 at 10:51:52 UTC, Adam Wilson wrote:

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


Oh, I remembered one wish:

Please, make Phobos modules disableable! Something like:

[...]
enum isFileIOisAvailable = __traits(compiles, /* some druntime 
filesIO-related code */);

static if (isFileIOisAvailable):
[...]

That is, for example, if the code using core.stdc.stdio.fopen is 
not compiles that means files or stream subsystem isn't available 
and, thus, it is not need to provide std.file module and so on 
related to the files/std streams subsystem.

The same is for any other Phobos modules relying on support of 
any hardware features.
Jun 22