You can find the final draft of the high-level goals for the D programming language at the following link:

https://github.com/dlang/vision-document

I'll fill out the remaining sections as time allows over the coming weeks. Once it's complete, I'll make sure it's linked in the Community section of the menu bar.

I want to emphasize that what we have there right now are a list of high-level goals. Please read my summary of our June meeting for more info on the motivation behind it.

https://forum.dlang.org/thread/buythmwbdaswuqbtkddv@forum.dlang.org

Some of these goals we want to actively pursue, others are things we'll take advantage of when the opportunity arises. For example, completing the memory safety story is an active project, but looking for features to remove, or to put on the "no recommended list" is something we'll evaluate when it comes up.

Improving the ecosystem is a major goal. Right now, we don't have the resources in place to make that happen, but we expect to be there next year once we have an ecosystem management team in place.

In the meantime, if you have an idea for a new tool or project that fits into our goals, and you don't want to start working on it until you know it's going have the foundation's approval or support, then please let me know. Hash out ideas of the project in the forums or on Discord if you need to, but we'll want you to bring a proposal to one of our monthly meetings for discussion. Then you'll know if it's worth your time. Just be aware that we do not have the resources to oversee things right now to the extent we would like, so anyone looking to make this kind of contribution should be self-motivated and independent. We'll support you as much as we can, and we may even be willing to pay out a contract in some cases, but for now you're largely going to be on your own.

I also want to reiterate that this is a living document. We will modify the goals as needed as time goes by.

Feedback is welcome.

On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:

Thank you for putting this in clear terms. I miss an overarching «primary use scenarios» to guide further language evolution. How do you know if new language features are good or bad if you have no scenarios to measure them up against?

It is nice to see that improved move semantics is a goal, then I guess ARC could be something one could envision down the line. That said, I am a bit disappointed that there is no hint of a departure from the current STOP-the-world GC regime, but I guess that is the reflecting reality. My interpretation of the vision document is that the core team sees no need to change the current GC strategy.

On Sunday, 3 July 2022 at 11:13:42 UTC, Ola Fosheim Grøstad wrote:

That's not something we've discussed yet. Right now, the focus is on plugging holes in the existing language, building out the ecosystem, and overhauling Phobos. These areas are where we see some of the loudest complaints. Language evolution doesn't really mean much until we get all of this sorted. But we'll start discussing it at some point, at which time you'll see some new high-level goals appear.

In the meantime, Walter and Atila will continue evaluating DIPs on a case-by-case basis. (Speaking of which, I want to look at overhauling the DIP process a bit some time next year).

That's right. But Walter wants to minimize its use in Phobos v2, and there's a strong desire to have a pay-as-you-go DRuntime. I'm not the person to speculate on how the GC fits into that, but I do know they don't yet want git rid of it. (On a related note, I'll soon be publishing a video of a conversation I had with Walter about origins of D, and he said something there about the GC that really surprised me.)

On Sunday, 3 July 2022 at 11:39:45 UTC, Mike Parker wrote:

Good point.

Yes, the Phobos issue is probably a good point, but I don't think the standard library prevents experienced developers from doing anything (People can write their own or use third party solutions).

Although I have been pro GC-free in the past, I am also not so sure if GC-free is the sweet spot in 2022 (due to Rust and C++ having reduced friction significantly).

To my mind the sweet spot for larger applications would be to write your own runtime/GUI-framework/libraries in @system and cover your @safe application code with a convenient «non-stop» (or at least only «local stop») GC/ARC solution.

But I understand that you cannot say anything specific on this at this point in time.

That would be interesting to hear more about as the GC was what surprised me the most when I first tried D as a C++ «descendant».

On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:

Had a hope to see the "complete started but abandoned features" point.

On Sunday, 3 July 2022 at 08:46:31 UTC, Mike Parker wrote:

This section is... light on details and does little to clear up if you share my goals.

My current take on this is that I believe something with c feature ser + templates are the future, their foundation extremely shaky and awful with c++ appearing to make it powerful by accident, and that I should be wherever there is the most sugar to make it livable.

This will mostly involve me wanting an endless stream of new features to play with. But this contradicts the earlier section about simplicity and avoiding complex features.

Templates generally get ugly syntax, alias when you want to store first class type, static if's everywhere, _______traits; so Id suggests that's updated to be complex features that affect standard code but generally be open to experimental features in the template space; so that templates are generally going to get the short end of the stick design-wise but that but open to exploring out the foundation meta programming needs.

You don't comment on how v2 should be organized.

Currently, I believe to write functional-style code your going to import 5 different std libs and at least algorithm and range. Is that going to continue or be fixed?

I find the naming conflicts of "write" to be fairly awful and makes import std; undoable and even if you always write out your imports, studio and file are often going to be used together. Will that be fixed?

etc. etc.

the goals of std v2 probably could get its own document.

Id suggest dropping std.experimental and get a std.community sort of thing going.

Where given snar did sumtypes as a subtype lib, then got into std.experimental, had to follow your process and whatever; and then finally got merged into std.

Instead, I'd suggest that snar makes an important lib, it gets noticed by the community, std.community.sumtype will point at snar's github either auto-downloaded or batched with compiler releases.

Have whatever legal disclaimer that std.community is not your responsibility, is kinda bad style to overuse and should be verified yourself. But have a curated list of community projects that have a soft thumbs up and that are easy to use. While dropping the std.experimental take that everyone says is a bad experience.

On Sunday, 3 July 2022 at 17:27:43 UTC, rikki cattermole wrote:

You can just use ints… It is better to do something commonly used well, than have features that not enough people use to get the quality up.

People who are willing to use 4 bytes per code point are probably using third party C-libraries that have their own representation, so you have to convert anyway?