The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or click here to continue anyway

My Vision of D’s Future – The D Blog

When Andrei Alexandrescu stepped down as deputy leader of the D programming language, I was asked to take over the role going forward. Its needless to say, but Ill say it anyway, that those are some pretty big shoes to fill.

Im still settling into my new role in the community and figuring out how I want to do things and what those things even are. None of this happens in a vacuum either, since Walter needs to be on board as well.

I was asked on the D forums to write a blog post on my dreams and way forward for D, so here it is. What Id like to happen with D in the near future:

Memory safety

But D has a GC!, I hear you exclaim. Yes, but its also a systems programming language with value types and pointers, meaning that today, D isnt memory safe. DIP1000 was a step in the right direction, but we have to be memory safe unless programmers opt-out via a I know what Im doing @trusted block or function. This includes transitioning to @safe by default.

Safe and easy concurrency

Were mostly thereusing the actor model eliminates a lot of problems that would otherwise naturally occur. We need to finalize shared and make everything @safe as well.

Make D the default implementation language

Ds static reflection and code generation capabilities make it an ideal candidate to implement a codebase that needs to be called from several different languages and environments (e.g. Python, Excel, R, ). Traditionally this is done by specifying data structures and RPC calls in an Interface Definition Language (IDL) then translating that to the supported languages, with a wire protocol to go along with it.

With D, none of that is necessary. One can write the production code in D and have libraries automagically make that code callable from other languages. Add to all of this that its possible and easy to write D code that runs as fast or faster than the alternatives, and its a win on all fronts.

Second to none reflection.

Instead of disparate ways of getting things done with fragmented APIs (__traits, std.traits, custom code), Id like for there to be a library that centralizes all reflection needs with a great API. Im currently working on it.

Easier interop with C++.

As I mentioned in my DConf 2019 talk, C++ has had the success its enjoyed so far by making the transition from C virtually seamless. I want current C++ programmers with legacy codebases to just as easily be able to start writing D code. Thats why I wrote dpp, but its not quite there yet and we might have to make language changes to accommodate this going forward.

Fast development times.

I think we need a ridiculously fast interpreter so that we can skip machine code generation and linking. To me, this should be the default way of running unittest blocks for faster feedback, with programmers only compiling their code for runtime performance and/or to ship binaries to final users. This would also enable a REPL.

String interpolation

I was initially against this, but the more I think about it the more it seems to make sense for D. Why? String mixins. Code generation is one of Ds greatest strengths, and token strings enable visually pleasing blocks of code that are actually just strings. String interpolation would make them vastly easier to use. As it happens, theres a draft DIP for it in the pipeline.

Thats what I came up with after a long walk by Lake Geneva. Id love to know what the community thinks of this, what their pet peeves and pet features would be, and how they think this would help or hinder D going forward.

Related

Continue reading on dlang.org