D (programming language)

D, also known as Dlang, is a multi-paradigm system programming language created by Walter Bright at Digital Mars and released in 2001. Andrei Alexandrescu joined the design and development effort in 2007. Though it originated as a re-engineering of C++, D is a distinct language. It has redesigned some core C++ features, while also sharing characteristics of other languages, notably Java, Python, Ruby, C#, and Eiffel.
The design goals of the language attempted to combine the performance and safety of compiled languages with the expressive power of modern dynamic languages. Idiomatic D code is commonly as fast as equivalent C++ code, while also being shorter. The language as a whole is not memory-safe but does include optional attributes designed to check memory safety.
Type inference, automatic memory management and syntactic sugar for common types allow faster development, while bounds checking, design by contract features and a concurrency-aware type system help reduce the occurrence of bugs.
Features.
D was designed with lessons learned from practical C++ usage, rather than from a purely theoretical perspective. Although the language uses many C and C++ concepts, it also discards some, or uses different approaches (and syntax) to achieve some goals. As such it is not source compatible (and does not aim to be) with C and C++ source code in general (some simpler code bases from these languages might by luck work with D, or require some porting). D has, however, been constrained in its design by the rule that any code that was legal in both C and D should behave in the same way. D gained some features before C++, such as closures, anonymous functions, compile-time function execution, ranges, built-in container iteration concepts and type inference. D adds to the functionality of C++ by also implementing design by contract, unit testing, true modules, garbage collection, first class arrays, associative arrays, dynamic arrays, array slicing, nested functions, lazy evaluation, scoped (deferred) code execution, and a re-engineered template syntax. D retains C++'s ability to perform low-level programming and to add inline assembler. C++ multiple inheritance was replaced by Java-style single inheritance with interfaces and mixins. On the other hand, D's declaration, statement and expression syntax closely matches that of C++.
The inline assembler typifies the differences between D and application languages like Java and C#. An inline assembler lets programmers enter machine-specific assembly code within standard D code, a method used by system programmers to access the low-level features of the processor needed to run programs that interface directly with the underlying hardware, such as operating systems and device drivers, as well as writing high-performance code (i.e. using vector extensions, SIMD) that is hard to generate by the compiler automatically.
D has built-in support for documentation comments, allowing automatic documentation generation.
Programming paradigms.
D supports five main programming paradigms: imperative, object-oriented, metaprogramming, functional and concurrent (actor model).
Imperative.
Imperative programming in D is almost identical to that in C. Functions, data, statements, declarations and expressions work just as they do in C, and the C runtime library may be accessed directly. On the other hand, some notable differences between D and C in the area of imperative programming include D's codice_1 loop construct, which allows looping over a collection, and nested functions, which are functions that are declared inside another and may access the enclosing function's local variables.
import std.stdio;
void main() {
 int multiplier = 10;
 foreach (i; 0 .. 10) {
 writefln("Hello, world %d! scaled = %d", i, scaled(i));
D also includes dynamic arrays and associative arrays by default in the language.
Symbols (functions, variables, classes) can be declared in any order - forward declarations are not required. Similarly imports can be done almost in any order, and even be scoped (i.e. import some module or part of it inside a function, class or unittest only).
D supports function overloading.
Object-oriented.
Object-oriented programming in D is based on a single inheritance hierarchy, with all classes derived from class Object. D does not support multiple inheritance; instead, it uses Java-style interfaces, which are comparable to C++'s pure abstract classes, and mixins, which separates common functionality from the inheritance hierarchy. D also allows the defining of static and final (non-virtual) methods in interfaces.
Interfaces and inheritance in D support covariant types for return types of overridden methods.
D supports operator overloading, type forwarding, as well optional custom dynamic dispatch.
Classes (and interfaces) in D can contain invariants which are automatically checked before and after entry to public methods. It is part of the design by contract methodology.
Many aspects of classes (and structs) can be introspected automatically at compile time (a form of reflection using codice_2) and at run time (RTII / codice_3), to facilitate generic code or automatic code generation (usually using compile-time techniques).
Metaprogramming.
Metaprogramming is supported by a combination of templates, compile-time function execution, tuples, and string mixins. The following examples demonstrate some of D's compile-time features.
Templates in D can be written in a more imperative style compared to the C++ functional style for templates. This is a regular function that calculates the factorial of a number:
ulong factorial(ulong n) {
 if (n < 2)
 return 1;
 else
 return n * factorial(n-1);
Here, the use of codice_4, D's compile-time conditional construct, is demonstrated to construct a template that performs the same calculation using code that is similar to that of the function above:
template Factorial(ulong n) {
 static if (n < 2)
 enum Factorial = 1;
 else
 enum Factorial = n * Factorial!(n-1);
In the following two examples, the template and function defined above are used to compute factorials. The types of constants need not be specified explicitly as the compiler infers their types from the right-hand sides of assignments:
enum fact_7 = Factorial!(7);
This is an example of compile-time function execution. Ordinary functions may be used in constant, compile-time expressions provided they meet certain criteria:
enum fact_9 = factorial(9);
The codice_5 function performs codice_6-like data formatting (also at compile-time, through CTFE), and the "msg" pragma displays the result at compile time:
import std.string : format;
pragma(msg, format("7! = %s", fact_7));
pragma(msg, format("9! = %s", fact_9));
String mixins, combined with compile-time function execution, allow generating D code using string operations at compile time. This can be used to parse domain-specific languages to D code, which will be compiled as part of the program:
import FooToD; // hypothetical module which contains a function that parses Foo source code
 // and returns equivalent D code
void main() {
 mixin(fooToD(import("example.foo")));
Functional.
D supports functional programming features such as function literals, closures, recursively-immutable objects and the use of higher-order functions. There are two syntaxes for anonymous functions, including a multiple-statement form and a "shorthand" single-expression notation:
int function(int) g;
g = (x) { return x * x; }; // longhand
g = (x) => x * x; // shorthand
There are two built-in types for function literals, codice_7, which is simply a pointer to a stack-allocated function, and codice_8, which also includes a pointer to the surrounding environment. Type inference may be used with an anonymous function, in which case the compiler creates a codice_8 unless it can prove that an environment pointer is not necessary. Likewise, to implement a closure, the compiler places enclosed local variables on the heap only if necessary (for example, if a closure is returned by another function, and exits that function's scope). When using type inference, the compiler will also add attributes such as codice_10 and codice_11 to a function's type, if it can prove that they apply.
Other functional features such as currying and common higher-order functions such as map, filter, and reduce are available through the standard library modules codice_12 and codice_13.
import std.stdio, std.algorithm, std.range;
void main()
 int[] a1 = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
 int[] a2 = [6, 7, 8, 9];
 // must be immutable to allow access from inside a pure function
 immutable pivot = 5;
 int mySum(int a, int b) pure nothrow // pure function
 if (b <= pivot) // ref to enclosing-scope
 return a + b;
 else
 return a;
 // passing a delegate (closure)
 auto result = reduce!mySum(chain(a1, a2));
 writeln("Result: ", result); // Result: 15
 // passing a delegate literal
 result = reduce!((a, b) => (b <= pivot) ? a + b : a)(chain(a1, a2));
 writeln("Result: ", result); // Result: 15
Alternatively, the above function compositions can be expressed using Uniform Function Call Syntax (UFCS) for more natural left-to-right reading:
 auto result = a1.chain(a2).reduce!mySum();
 writeln("Result: ", result);
 result = a1.chain(a2).reduce!((a, b) => (b <= pivot) ? a + b : a)();
 writeln("Result: ", result);
Parallel.
Parallel programming concepts are implemented in the library, and do not require extra support from the compiler. However the D type system and compiler ensure that data sharing can be detected and managed transparently.
import std.stdio : writeln;
import std.range : iota;
import std.parallelism : parallel;
void main()
 foreach (i; iota(11).parallel) {
 // The body of the foreach loop is executed in parallel for each i
 writeln("processing ", i);
codice_14 is equivalent to codice_15 by using UFCS.
The same module also supports codice_16 that can be used for dynamic creation of parallel tasks, as well map-filter-reduce and fold style operations on ranges (and arrays), which is useful when combined with functional operations:
import std.stdio : writeln;
import std.algorithm : map;
import std.range : iota;
import std.parallelism : taskPool;
void main()
 auto nums = iota(1.0, 1_000_000_000.0);
 auto x = taskPool.reduce!"a + b"(
 0.0, map!"1.0 / (a * a)"(nums)
 writeln("Sum: ", x);
 // On Intel i7-3930X and gdc 9.3.0:
 // 5140ms using std.algorithm.reduce
 // 888ms using std.parallelism.taskPool.reduce; 
 // On AMD Threadripper 2950X, and gdc 9.3.0:
 // 2864ms using std.algorithm.reduce
 // 95ms using std.parallelism.taskPool.reduce
This code uses fact that the codice_17 does not actually return an array, but a lazily evaluate range, this way the actual elements of the map are computed by each worker task in parallel automatically.
Concurrent.
Concurrent programming is fully implemented in the library, and does not require any special support from the compiler. Alternative implementations and methodologies of writing concurrent code are possible. The use of D typing system does help ensure memory safety.
import std.stdio, std.concurrency, std.variant;
void foo()
 bool cont = true;
 while (cont)
 receive( // Delegates are used to match the message type.
 (int msg) => writeln("int received: ", msg),
 (Tid sender) { cont = false; sender.send(-1); },
 (Variant v) => writeln("huh?") // Variant matches any type
void main()
 auto tid = spawn(&foo); // spawn a new thread running foo()
 foreach (i; 0 .. 10)
 tid.send(i); // send some integers
 tid.send(1.0f); // send a float
 tid.send("hello"); // send a string
 tid.send(thisTid); // send a struct (Tid)
 receive((int x) => writeln("Main thread received message: ", x));
Memory management.
Memory is usually managed with garbage collection, but specific objects may be finalized immediately when they go out of scope. This is what majority of programs and libraries written in D use.
In case more control about memory layout and better performance is needed, explicit memory management is possible using the overloaded operators codice_18 and codice_19, by calling C's malloc and free directly, or implementing custom allocator schemes (i.e. on stack with fallback, RAII style allocation, reference counting, shared reference counting). Garbage collection can be controlled: programmers may add and exclude memory ranges from being observed by the collector, can disable and enable the collector and force either a generational or full collection cycle. The manual gives many examples of how to implement different highly optimized memory management schemes for when garbage collection is inadequate in a program.
In functions, codice_20 are by default allocated on the stack, while codice_21 by default allocated on the heap (with only reference to the class instance being on the stack). However this can be changed for classes, for example using standard library template codice_22, or by using codice_18 for structs and assigning to pointer instead to value-based variable.
In function, static arrays (of known size) are allocated on stack. For dynamic arrays one can use codice_24 function (similar to C function codice_25, to allocate memory on stack. The returned pointer can be used (recast) into a (typed) dynamic array, by means of a slice (however resizing array, including appending must be avoided; and for obvious reasons they must not be returned from the function).
A codice_26 keyword can be used both to annotate parts of code, but also variables and classes/structs, to indicate they should be destroyed (destructor called) immediately on scope exit. Whatever the memory is deallocated also depends on implementation and class-vs-struct differences.
codice_27 contains a modular and composable allocator templates, to create custom high performance allocators for special use cases.
SafeD.
SafeD
is the name given to the subset of D that can be guaranteed to be memory safe (no writes to memory that has not been allocated or that has been recycled). Functions marked codice_28 are checked at compile time to ensure that they do not use any features that could result in corruption of memory, such as pointer arithmetic and unchecked casts, and any other functions called must also be marked as codice_28 or codice_30. Functions can be marked codice_30 for the cases where the compiler cannot distinguish between safe use of a feature that is disabled in SafeD and a potential case of memory corruption.
Scope Lifetime Safety.
Initially under the banners of DIP1000 and DIP25 (now part of the language specification), D provides protections against certain ill-formed constructions involving the lifetimes of data.
The current mechanisms in place primarily deal with function parameters and stack memory however it is a stated ambition of the leadership of the programming language to provide a more thorough treatment of lifetimes within the D programming language. (Influenced by ideas from Rust programming language).
Lifetime Safety of Assignments.
Within @safe code, the lifetime of an assignment involving a reference type is checked to ensure that the lifetime of the assignee is longer than that of the assigned.
For example:
@safe void test()
 int tmp = 0; // #1
 int* rad; // #2
 rad = &tmp; // If the order of the declarations of #1 and #2 is reversed, this fails.
 int bad = 45; // Lifetime of "bad" only extends to the scope in which it is defined.
 *rad = bad; // This is kosher.
 rad = &bad; // Lifetime of rad longer than bad, hence this is not kosher at all. 
Function Parameter Lifetime Annotations within @safe code.
When applied to function parameter which are either of pointer type or references, the keywords "return" and "scope" constrain the lifetime and use of that parameter. 
The Standard Dictates the following behaviour:
An Annotated Example is given below.
@safe:
int* gp;
void thorin(scope int*);
void gloin(int*);
int* balin(return scope int* p, scope int* q, int* r)
 gp = p; // error, p escapes to global gp
 gp = q; // error, q escapes to global gp
 gp = r; // ok
 thorin(p); // ok, p does not escape thorin()
 thorin(q); // ok
 thorin(r); // ok
 gloin(p); // error, gloin() escapes p
 gloin(q); // error, gloin() escapes q
 gloin(r); // ok that gloin() escapes r
 return p; // ok
 return q; // error, cannot return 'scope' q
 return r; // ok
Interaction with other systems.
C's application binary interface (ABI) is supported, as well as all of C's fundamental and derived types, enabling direct access to existing C code and libraries. D bindings are available for many popular C libraries. Additionally, C's standard library is part of standard D.
On Microsoft Windows, D can access Component Object Model (COM) code.
As long as memory management is properly taken care of, many other languages can be mixed with D in a single binary. For example GDC compiler allow to link C, C++, and other supported language codes to be intermixed. D code (functions) can also be marked as using C, C++, Pascal ABIs, and thus be passed to the libraries written in these languages as callbacks. Similarly data can be interchanged between the codes written in these languages in both ways. This usually restricts use to primitive types, pointers, some forms of arrays, unions, structs, and only some types of function pointers.
Because many other programming languages often provide the C API for writing extensions or running the interpreter of the languages, D can interface directly with these languages as well, using standard C bindings (with a thin D interface file). For example, there are bi-directional bindings for languages like Python, Lua and other languages, often using compile-time code generation and compile-time type reflection methods.
Interaction with C++ code.
D takes a permissive but realistic approach to interoperation with C++ code.
For D code marked as "extern(C++)", the following features are specified:
C++ namespaces are used via the syntax "extern(C++, namespace)" where "namespace" is the name of the C++ namespace.
An Example of C++ interoperation.
The C++ side
using namespace std;
class Base
 public:
 virtual void print3i(int a, int b, int c) = 0;
class Derived : public Base
 public:
 int field;
 void print3i(int a, int b, int c)
 cout « "a = " « a « endl;
 cout « "b = " « b « endl;
 cout « "c = " « c « endl;
 int mul(int factor);
int Derived::mul(int factor)
 return field * factor;
Derived *createInstance(int i)
 return new Derived(i);
void deleteInstance(Derived *&d)
 delete d;
 d = 0;
 
The D side
extern(C++)
 abstract class Base
 void print3i(int a, int b, int c);
 class Derived : Base
 int field;
 @disable this();
 override void print3i(int a, int b, int c);
 final int mul(int factor);
 Derived createInstance(int i);
 void deleteInstance(ref Derived d);
void main()
 import std.stdio;
 auto d1 = createInstance(5);
 writeln(d1.field);
 writeln(d1.mul(4));
 Base b1 = d1;
 b1.print3i(1, 2, 3);
 deleteInstance(d1);
 assert(d1 is null);
 auto d2 = createInstance(42);
 writeln(d2.field);
 deleteInstance(d2);
 assert(d2 is null);
Better C.
The D programming language has an official subset known as "". This subset forbids access to D features requiring use of runtime libraries other than that of C.
Enabled via the compiler flags "-betterC" on DMD and LDC, and "-fno-druntime" on GDC, may only call into D code compiled under the same flag (and linked code other than D) but code compiled without the option may call into code compiled with it: This will, however, lead to slightly different behaviours due to differences in how C and D handle asserts.
History.
Walter Bright started working on a new language in 1999. D was first released in December 2001 and reached version 1.0 in January 2007. The first version of the language (D1) concentrated on the imperative, object oriented and metaprogramming paradigms, similar to C++.
Some members of the D community dissatisfied with Phobos, D's official runtime and standard library, created an alternative runtime and standard library named Tango. The first public Tango announcement came within days of D 1.0's release. Tango adopted a different programming style, embracing OOP and high modularity. Being a community-led project, Tango was more open to contributions, which allowed it to progress faster than the official standard library. At that time, Tango and Phobos were incompatible due to different runtime support APIs (the garbage collector, threading support, etc.). This made it impossible to use both libraries in the same project. The existence of two libraries, both widely in use, has led to significant dispute due to some packages using Phobos and others using Tango.
In June 2007, the first version of D2 was released. The beginning of D2's development signaled D1's stabilization. The first version of the language has been placed in maintenance, only receiving corrections and implementation bugfixes. D2 introduced breaking changes to the language, beginning with its first experimental const system. D2 later added numerous other language features, such as closures, purity, and support for the functional and concurrent programming paradigms. D2 also solved standard library problems by separating the runtime from the standard library. The completion of a D2 Tango port was announced in February 2012.
The release of Andrei Alexandrescu's book "The D Programming Language" on June 12, 2010, marked the stabilization of D2, which today is commonly referred to as just "D".
In January 2011, D development moved from a bugtracker / patch-submission basis to GitHub. This has led to a significant increase in contributions to the compiler, runtime and standard library.
In December 2011, Andrei Alexandrescu announced that D1, the first version of the language, would be discontinued on December 31, 2012. The final D1 release, D v1.076, was on December 31, 2012.
Code for the official D compiler, the "Digital Mars D compiler" by Walter Bright, was originally released under a custom license, qualifying as source available but not conforming to the open source definition. In 2014 the compiler front-end was re-licensed as open source under the Boost Software License. This re-licensed code excluded the back-end, which had been partially developed at Symantec. On April 7, 2017, the entire compiler was made available under the Boost license after Symantec gave permission to re-license the back-end, too. On June 21, 2017, the D Language was accepted for inclusion in GCC.
As of GCC 9, GDC (short for GNU D Compiler, or GCC D Compiler), a D language frontend based on DMD open source frontend was merged into GCC.
Implementations.
Most current D implementations compile directly into machine code for efficient execution.
Production ready compilers:
Toy and proof-of-concept compilers:
Using above compilers and toolchains, it is possible to compile D programs to target many different architectures, including x86, amd64, AArch64, PowerPC, MIPS64, DEC Alpha, Motorola m68k, Sparc, s390, WebAssembly. The primary supported operating system are Windows and Linux, but various compiler supports also Mac OS X, FreeBSD, NetBSD, AIX, Solaris/OpenSolaris and Android, either as a host or target, or both. WebAssembly target (supported via LDC and LLVM) can operate in any WebAssembly environment, like modern web browser (Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari), or dedicated Wasm virtual machines.
Development tools.
Editors and integrated development environments (IDEs) supporting D include Eclipse, Microsoft Visual Studio, SlickEdit, Emacs, vim, SciTE, Smultron, TextMate, MonoDevelop, Zeus, and Geany among others.
Additionally many other editors and IDE support syntax highlighting and partial code / identifier completion for D.
Open source D IDEs for Windows exist, some written in D, such as Poseidon, D-IDE, and Entice Designer.
D applications can be debugged using any C/C++ debugger, like GDB or WinDbg, although support for various D-specific language features is extremely limited. On Windows, D programs can be debugged using Ddbg, or Microsoft debugging tools (WinDBG and Visual Studio), after having converted the debug information using cv2pdb. The ZeroBUGS debugger for Linux has experimental support for the D language. Ddbg can be used with various IDEs or from the command line; ZeroBUGS has its own graphical user interface (GUI).
A DustMite is a powerful tool for minimize D source code, useful when finding compiler or tests issues.
dub is a popular package and build manager for D applications and libraries, and is often integrated into IDE support.
Examples.
Example 1.
This example program prints its command line arguments. The codice_34 function is the entry point of a D program, and codice_35 is an array of strings representing the command line arguments. A codice_36 in D is an array of characters, represented by codice_37.
import std.stdio: writefln;
void main(string[] args) {
 foreach (i, arg; args)
 writefln("args[%d] = '%s'", i, arg);
The codice_1 statement can iterate over any collection. In this case, it is producing a sequence of indexes (codice_39) and values (codice_40) from the array codice_35. The index codice_39 and the value codice_40 have their types inferred from the type of the array codice_35.
Example 2.
The following shows several D capabilities and D design trade-offs in a short program. It iterates over the lines of a text file named codice_45, which contains a different word on each line, and prints all the words that are anagrams of other words.
import std.stdio, std.algorithm, std.range, std.string;
void main() {
 dstring[] [dstring] signature2words;
 foreach (dchar[] w; lines(File("words.txt"))) {
 w = w.chomp().toLower();
 immutable signature = w.dup.sort().release().idup;
 signature2words[signature] ~= w.idup;
 foreach (words; signature2words) {
 if (words.length > 1) {
 writeln(words.join(" "));
Uses.
Notable organisations that use the D programming language for projects include Facebook, eBay, and Netflix.
D has been successfully used for AAA games, language interpreters, virtual machines, an operating system kernel, GPU programming, web development, numerical analysis, GUI applications, a passenger information system, machine learning, text processing, web and application servers and research.