The D programming language

Today Andrei is going to tell us about the D programming language, after his previous talks on C++ earlier this week.
The core ideas of D are:
  • Efficient when it can
  • Convinient when it should
  • Safe when it must

D is statically typed and uses deduction wherever possible.


Having memory safety means that all data is read with the same type it was written, this makes bugs reproducible and ensures the type system works correctly.

But the challenge is that you also want recycle memory early and circumvent the type system when that is efficient. So the compromise is that not all of D can be safe. A safe subset was created that is tagged with the @safe attribute, this subset is usable for many programs. “Unsafe” functions are tagged with @system. @safe function cannot call @system functions or forge, cast or perform arithmetic on pointers.

There is a third option: @trusted These are functions that are safe but this is not provable and needs to be manually checked by the programmer.


Andrei states that purity is useful, but writing pure code only is very difficult. The official definition of purity is no side effects. Andrei changes this into: pure functions always return the same results for the same input. No reading and writing of global variables (reading global constants okay). No calling of impure functions. Local state inside the pure functions are allowed. Functions that are pure in this sense are annotated with ‘pure’. More on D’s purity here.

More D after the break.