Pattern matching
Hopefully that includes proper built in Tagged Union, non OOP people need that otherwise we are stuck in C's era of programming
We can, and we should do better (import std.sumtype is embarrassing when other languages have it built in without template soup, i still refuse to touch it)
>Tuples
Awesome! hopefully they become built in and more integrated
>Async/await
This one will be tricky, done well means it scale from 0 to hearo, meaning i should be able to use it without the need of a GC
Hopefully it's not one of these import std.concurency: async, await, frame;
Stronger traits
That's awesome to hear, metaprogramming is one of D's strength
On the tooling part:
A language server is long overdue..
https://pkg.go.dev/golang.org/x/tools/gopls
https://blog.rust-lang.org/2022/07/01/RLS-deprecation.html
https://rust-analyzer.github.io/
The one we have right now (serve-d) is nice, but uses the same backend as every other projects (DCD), and this project haven't evolved in years, the moment you step into template territory, it falls short T get(T)() { return T.init } auto myInt = get!int;
it'll not know what myInt is.. wich is a shame when that feature is D's signature
A better debugging story is also essential, without having to use external (incomplete) files like: https://github.com/Pure-D/dlang-debug
msvc, clang, gcc: they should know what D types are, and they should be able to step properly into D syntax without the need of the user to do weird things
Zig is a young language and yet has a better debugging story
Onto the phobos/druntime:
That's nice to hear that the goal is to reduce inter module dependencies
Core APIs should be made independent and VERY simple, this allows them to be easily ported to other platforms, easier to extend
I am sad that no word on the Allocator API, moving forward i personally think APIs that use memory should be required to ask for an Allocator and do their allocation using it, and only it
A default GCAllocator could be used if none provided, this allows users of all kind to enjoy the APIs without having to complain about the GC or their inability to integrate the APIs in their game engine for example
--
Overall this document is super encouraging, thanks for making it, D finally have a long term roadmap!
Hopefully this allows everyone to align and coordinate their efforts
I wish i could help, i tried, but language programming is definitely not my cup of tea, hopefully you guys are not sick of my suggestions
A language is about allowing user to express their intent, making it easier for them to achieve that goal is a priority, compiler internal difficulties should not prevent language improvements, compiler internals doesn't exist from the user point of view