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

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

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

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

+1

+1

+1

+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

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

Will there be a plan to put Phobos 2 on life support and eventually sunset it? It doesn't make sense to support that forever.

On Friday, 2 February 2024 at 19:39:34 UTC, Lance Bachmeier wrote:

If I'm not mistaken Go has this for over 10 years now. I'm not aware of any other language/ecosystem that followed this.

On Friday, 2 February 2024 at 19:39:34 UTC, Lance Bachmeier wrote:

But that's not true is it? How does it know which versions of the package are acceptable? Which of the acceptable versions does it pull? How does it handle the packages' dependencies? You simply cannot have the compiler pull a package without going through the entire dependency resolution process. Which means you're building DUB into DMD. Compilers are not package managers. I've asked Walter about this idea before and the reception was ... not positive, so probably best to just drop it.

That's not a reason. You're saying that you know what the reason is, that you're not going to state the reason, but that your special knowledge is so perfect that you can confidently state a ridiculous timeline as fact? I would suggest that you might want to consider how superlatively arrogant that sounds. DConf 2024 is probably a stretch, but sometime in 2025 is probably realistic, unless the money floodgates open and time can be purchased, but I'm not holding my breath for that outcome.

That is pretty much where this is going to end. Walter and I discussed tying Phobos releases to Compiler Editions, and he was amenable to the idea, his only sticking point was to not use "Editions" to describe Phobos, and "Versions" or "Releases" works just fine for our purposes. I would expect to see Phobos 3 land with the first Edition. Both of which I would expect in 2025.

I am sorry to hear that it's not getting there as fast as you want it to, but that is the nature of volunteer projects, so unless you're willing to step up and help out, it's going to happen at pretty much whatever pace the rest of us can afford. But don't expect much sympathy when you're whining about a problem you're not doing anything to help solve.

Yes and no, so long as the primary volunteers working on a specific piece stay the same then yes, expect similar results. But change out the personnel and I would expect the results to change. This is also true in a for-profit corp, but to a lesser degree, as volunteers are usually far less restricted by onerous policies.

If I run Phobos development, I will run it differently. Walter has asked that I not go crazy, but so far everything I've talked about has been met with some variant of "that's ... different" so skepticism yes, but so far Walter and the DLF have been willing to extend me that latitude.

On Friday, 2 February 2024 at 21:11:51 UTC, Andrea Fontana wrote:

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.

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.

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.

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.

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.

On Saturday, 3 February 2024 at 03:49:54 UTC, Adam Wilson wrote:

What typeinfo/moduleinfo has to do with a networking module in the STD for example?

Dynamic array/associative array can be made to work with -betterC, i mentioned in my reply above, minimal allocator API in core.memory make associative array able to change its allocator, and build APIs in phobos around allocators and people who use betterC will be able to consume phobos without people working on phobos having to know/care about betterC

If you care about simplicity and efficiency, obviously

On Saturday, 3 February 2024 at 11:53:05 UTC, ryuukk_ wrote:

Oh, and Exception Handling?

Get in native tuple and tagged union in the language, and you'll be able to build nice error handling code

I hope no EH in Phobos 3

On Saturday, 3 February 2024 at 11:54:48 UTC, ryuukk_ wrote:

Existing try catch syntax could be improved to support tagged union you've mentioned btw. Compiler then would inject extra code on each statement that returns a tagged union to automatically forward to appropriate catch clause, if an exception is returned from said statement.

On Saturday, 3 February 2024 at 03:49:54 UTC, Adam Wilson wrote:

Obviously we are not going to get all of Phobos to work with BetterC, but significant chunks of it already do, and there's a good deal more that could be considered low-hanging fruit.

I think the right approach here is to try to make code BetterC-compatible when we can, and to at least keep BetterC compatibility in mind as a "nice-to-have" goal (but not a requirement) when doing API design. For example, if the only thing keeping a function from being BetterC-compatible is that it uses the GC to allocate memory for an error message, it's probably worth a little bit of extra effort to either get rid of that GC dependency, or provide a version (D_BetterC) alternative.