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
