The D Programming Language Vision Document

[ryuukk_]

> 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