The D Programming Language

D is an advanced systems programming language. It is designed to appeal to C and C++ programmers who need a more powerful language that has a much lower complexity and hence is easier to master. D is multiparadigm, and looks and feels very much like C and C++. It offers opportunities for advanced compilers to generate more efficient code than is possible for C/C++, while supporting facilities that reduce the probability of program bugs.

Why D?

Refactoring

Difficulty in adding modern new features

While C++ is pioneering generic programming practice, it lags behind in other modern techniques such as Contract Programming, modules, automated testing, and automatic memory management, It's very difficult to add these while still supporting legacy code.

Brief Tour

	import std.c.stdio;

	int main()
	{
	    printf("Hello world\n");
	    return 0;
	}
	

Look and feel is very much like C and C++

I am so, so used to C/C++ syntax that I feel like that poor guy when faced with a new and improved language that also turns the syntax inside out (or so it looks to me). Frankly, I rarely give such languages a chance even when the feature set looks intriguing. D doesn't take that route, its syntax is as comfortable to C/C++ programmers as an old shoe. Functions, statements, expressions, operator precedence, integral promotions, it's all there pretty much unchanged. The world is right side up, it's just got brighter colors and sharper focus!

Since D is so similar to C/C++, the rest of the article will focus on characteristics that distinguish it.

Binary compatibility with C

There is no direct D interface to C++, but the two languages can talk to each other because they both support C interfaces.

Retains and even expands access to low level programming

Clean separation between lexical analysis, syntactic analysis, and semantic analysis.

For the kinds of troubles this avoids, see the infamous "template angle bracket hack" in C++. Add up all the time highly paid professionals have spent reading about it, writing about it, explaining it to other programmers, proposing fixes for it, and multiply by their hourly cost.

Modules

No forward declarations needed!

	void foo() { bar(); }	// forward reference OK
	void bar() { }
	

No preprocessor

Unicode

Interfaces

Function in, out, inout parameters

	void ham()
	{   int x = 1, y = 2, z = 3;

	    eggs(x, y, z);
	}

	void eggs(in int a, out int b, inout int c)
	{
	    a += 1;	// x is not affected
	    b = 4;	// y is set to 4
	    c *= 3;	// z is set to 9
	}
	

Automatic memory management

RAII

Explicit memory allocation

Arrays

Array bounds checking is performed, eliminating a very common and mundane cause of bugs (infamously called 'buffer overflow' bugs). Bounds checking, being a runtime check, can be expensive, and so can be optionally removed for release builds.

Associative Arrays

	int[ char[] ] keywords;
	char[] abc;
	...
	keywords["foo"] = 3;	// initialize table
	...
	if (keywords[abc] == 3)	// look up keyword
	    ...
	

	int[int] sa;
	sa[1] = 3;
	sa[1000] = 16;
	

Symbol table

Nested functions

	int foo()
	{
	    int x = 3;

	    int bar(int z) { return x + z; }

	    return bar(2) * bar(3);
	}
	

Delegates

Function literals

	double parabola(double x, double y)
	{
	    return integrate(0.0, x,
		function double (double x) { return y * x; });
	}

	double integrate(double x1, double x2, double delegate(double dx) f)
	{   double sum = 0;
	    double dx = 0.0001;
	    for (double x = x1; x < x2; x += dx)
		sum += f(x) * dx;
	    return sum;
	}
	

Exception handling

Although not required by the semantics of the language, D adopts the pattern of using exceptions to signal error conditions rather than using error return codes.

Contract Programming

Typical documentation for code is either wrong, out of date, misleading, or absent. Contracts in many ways substitute for documentation, and since they cannot be ignored and are verified automatically, they have to be kept right and up to date.

DbC is a significant cornerstone of improving the reliability of programs.

DbC can be done in C++, but to do it fully winds up looking a lot like implementing polymorphism in C. Building the constructs for it into the language makes it easy and natural, and hence much more likely to be used.

Unit testing

In my experience using unit tests and not using unit tests, the places where I've used it have wound up being much more reliable, even in the presence of an external test suite. But of course this is obvious, but if it's so obvious, why do we rarely see unit tests in production code? D's presumption is that the problem is the lack of a consistent, portable, easy, language supported unit test system.

Minor feature improvements

No need for -> operator

	    struct X { int a; }
	    ...
	    X x;
	    X* px;
	    ...
	    x.a;     // access X.a
	    px.a;    // access X.a
	

Anonymous structs/unions for member layout

	    struct Foo
	    {	int x;
		union
		{  int a;
		   struct { int b, c; }
		   double d;
		}
	    }
	

	    struct Foo
	    {   int x;
		union
		{   int a;
		    struct { int b, c; } s;
		    double d;
		} u;
	    };
	

Struct member alignment control

	    struct Foo
	    {
		align (4) char c;
		int a;
	    }
	

Easier declaration syntax

	    int *(**p[]);
	

	    int*[]** p;
	

Unsigned right shift >>>

	    int x;
	    ...
	    int i = (unsigned)x << 3;
	

Having a separate right shift operator eliminates this subtle source of bugs.

Embedded _ in numeric literals

Imaginary suffixes

	    cdouble c = 6 + 7i; // initialize complex double c
	

	    double complex c = 6 + 7 * I;
	

	    complex<double> c = complex<double>(6, 7);
	

WYSIWYG strings

		"y\\B\\w"	// regular strings
		r"y\B\w"	// WYSIWYG strings
	

		file("\\dm\\include\\stdio.h")	// regular strings
		file(r"\dm\include\stdio.h")	// WYSIWYG strings
	

X strings

		00 0A E3 DC 86 73 7E 7E
	

		0x00, 0x0A, 0xE3, 0xDC, 0x86, 0x73, 0x7E, 0x7E,
	

		"\x00\x0A\xE3\xDC\x86\x73\x7E\x7E"
	

		x"00 0A E3 DC 86 73 7E 7E"
	

Debug conditionals

	    debug (FooLogging) printf("checking foo\n");
	

Versioning

	    version (Windows)
	    {
		... windows version ...
	    }
	    else version (linux)
	    {
		... linux version ...
	    }
	    else
	    {
		static assert(0);	// unsupported system
	    }
	

Deprecation

		deprecated int foo() { ... }
	

Deprecated is an ideal tool for library vendors to use to mark functions that are obsolete and may be removed in future versions.

Switch strings

	    int main(char[][] args)
	    {
		foreach (char[] arg; args)
		{   switch (arg)
		    {	case "-h": printHelpMessage(); break;
			case "-x": setXOption(); break;
			default: printf("Unrecognized option %.*s\n", arg); break;
		    }
		}
		...
	    }
	

Module initializers

	    module foo;

	    static this()
	    {
		... initialization code ...
	    }
	

Static asserts

	    T x;
	    ...
	    static assert(x.size == (int*).size);
	

Default initializers

	    int x = 3;	// x is initialized to 3
	    int y;	// y is initialized to y.init, which is 0
	    double d;	// d is initialized to d.init, which is NAN
	

	    typedef int T = 4;
	    T t;	// t is initialized to T.init, which is 4
	

	    class Foo
	    {	int x;
		int y = 4;
		int z;
		this() { z = 5; }
	    }

	    Foo f = new Foo();
	    printf("%d, %d, %d\n", f.x, f.y, f.z); // prints 0, 4, 5
	

Synchronized

	    synchronized
	    {
		...	// critical section - only one thread at a time here
	    }

	    synchronized (o)
	    {
		...	// only one thread using Object o at a time here
	    }

	    class C
	    {
		// only one thread can use this.foo() at a time
		synchronized int foo();

		// only one thread at a time can execute bar()
	        synchronized static int bar();
	    }
	

Nested comments

Const means constant

Advanced Features

Operator overloading

Operator overloads for non-commutative operators like / have a special 'reverse' operator overload. This means that the C++ asymmetry of having member forward overloads and global reverse overloads is not necessary. Global operator overloads are not necessary, and eliminating them removes the requirement for ADL. Not having ADL implies that templates can be in imported modules without having complicated symbol lookup semantics.

Foreach iteration

Furthermore, the body of the foreach does not have to be a separate function. It can be a collection of arbitrary statements just like the body of a standard for loop or a while loop. It looks like:

	foreach (T v; collection)
	{
	    ... statements ...
	}
	

Templates

In particular, D supports class templates, function templates, partial specialization, explicit specialization, and partial ordering. Template parameters can be types, values, or other templates.

But it isn't just a boring clone of C++ templates. D corrects some of the root problems and extends template technology in several directions.

Template problems corrected:

		Foo<int>	// C++ template instantiation
		Foo!(int)	// D template instantiation
	

Since D has a module system rather than #include, separate compilation of templates follows naturally from the symbol table rules of imports. There is no need for an export keyword or any of the grief trying to implement it. It comes for free.

Another aspect of the module system is that there are no template declarations, there are only template definitions. Just import the module containing the template definition needed, and the language takes care of the rest.

D templates do not recognize a difference between point of instantiation and point of definition when dealing with forward references. All forward references are visible.

Closely related templates, rather than being defined separately with no obvious connection between them, can be declared as one template with its own scope:

		template Foo(T)
		{
		    struct bar { T t; }

		    void func(T t} { ... }
		}
	

Template Extensions:

Class templates (in fact, all templates) are overloadable.

The much discussed 'typeof' is supported as a standard part of the language. Similar facilities for type detection and manipulation are first class aspects of D, rather than needing macros or trait templates. For example, common properties of types can be accessed directly:

		T t;
		t.max;	// maximum value
		t.min;	// minimum value
		t.init;	// default initializer
	

Inline assembler

Standardizing the inline assembler means that one's inline assembler code will be portable from compiler to compiler (as long as it's on the same CPU). This is quite unlike the C/C++ world, where every compiler vendor extends the language with an inline assembler incompatible with all the others.

The D runtime library proves the worth of a standardized inline assembler by implementing many routines in inline assembly; the code is identical between the Windows and Linux versions.

Advantages of D

Simpler and faster to learn

There's no need for multiple warning levels in D, a "D Puzzle Book", a lint program, a "Bug Of The Month", or a world's leading expert on preprocessor token concatenation.

Retains investment in existing C code

There's no need to convert C code to D; new functionality can be written in D and linked in to the existing C object code. Indeed, some parts of the standard library - e.g. std.zlib, std.recls - are widely used C and C++ libraries that have been incorporated with no changes, only D declaration files were created for the libraries' C interfaces.

More portable

• char is unsigned. With C/C++, it is hard to verify that code using chars is portable without actually trying it on one compiler where chars are signed and another where they are unsigned. D doesn't have that problem; chars are unsigned.
• Integral types are fixed sizes. No more need for those endless typedef'ing schemes one sees in C/C++ code to get a fixed integral type size.
• Floating point is IEEE 754. This means that NaN's and infinities work, rounding is well behaved, and comparisons when one operand is a NaN are handled properly.
• Order of module initialization is specified.
• Source text is unicode, not some unspecified multibyte encoding.
• wchar is a 2 byte UTF-16 character, not 2 bytes on one machine and 4 bytes on another.
• It's far easier to write a compiler for D, meaning that there will be better conformance of various D implementations to the D standard.

More robust

D starts with ensuring that no variables or object members get left uninitialized - a common source of random bugs in C/C++. It follows up with the replacement of arbitrary pointers with arrays and array bounds checking. (No more buffer overflows overwriting the stack.)

Next, and most important, are Contract Programming and unit testing. Let's face it, test and verification of code is often clumsily done at the last minute, or not done at all. (How many times have you seen the source to a shipping program with no tests or verification code at all?).

The answer isn't to force programmers to write test and verification code, it's to make it easy to do it and manage it. Easy enough to tip the balance and make adding such as much a matter of course as adding comments. Having the test and verify code right there in the source along with the algorithm code also brings to bear peer pressure and management pressure to add it in. Having test (unit test) and verify (Contract Programming) code in with the algorithm will become as normal and expected as adding in explanatory comments.

With the difference that the test and verify code actually runs.

Pointers

Better code generation

• Compiler has semantic access to modules and potentially the entire program, rather than being restricted to a single source file and its #include'd headers.
• Compiler can look at forward references. For example, a function appearing lexically after its use can still be inlined. Any function is potentially inlineable - it doesn't need to be declared as inline.
• Higher level constructs that enable better optimization with simpler compilers. For example, D's foreach is built in to the language making it simple for the compiler to emit an optimized loop traversal. C and C++ compilers, on the other hand, need to do some fairly advanced analysis to detect loops, determine the loop counters, etc.
• Contracts (from asserts, Contract Programming) must evaluate to true, so optimizers can mine them for more information about data. Other language guarantees about the state of data, such as array bounds checking, can be used by the optimizer.

Straightforward symbol table

Open source reference implementation

Example

• It's close look and feel similarity to C.
• Use of imports rather than #include.
• New declaration syntax.
• Default initialization.
• Ability to seamlessly call C functions such as printf.
• Use of an associative array (dictionary) as a simple symbol table.
• Using foreach to iterate through different kinds of collections.
• Use of arrays.
• Use of array slicing (args[1 .. args.length]).

	import std.c.stdio;
	import std.file;

	int main (char[][] args)
	{
	    int w_total;
	    int l_total;
	    int c_total;
	    int[char[]] dictionary;

	    printf("   lines   words   bytes file\n");
	    foreach (char[] arg; args[1 .. args.length])
	    {
		char[] input;
		int w_cnt, l_cnt, c_cnt;
		int inword;
		int wstart;

		input = cast(char[])std.file.read(arg);

		for (int j = 0; j < input.length; j++)
		{   char c;

		    c = input[j];
		    if (c == '\n')
			++l_cnt;
		    if (c >= '0' && c <= '9')
		    {
		    }
		    else if (c >= 'a' && c <= 'z' ||
			c >= 'A' && c <= 'Z')
		    {
			if (!inword)
			{
			    wstart = j;
			    inword = 1;
			    ++w_cnt;
			}
		    }
		    else if (inword)
		    {   char[] word = input[wstart .. j];

			dictionary[word]++;
			inword = 0;
		    }
		    ++c_cnt;
		}
		if (inword)
		{   char[] w = input[wstart .. input.length];
		    dictionary[w]++;
		}
		printf("%8lu%8lu%8lu %.*s\n", l_cnt, w_cnt, c_cnt, arg);
		l_total += l_cnt;
		w_total += w_cnt;
		c_total += c_cnt;
	    }

	    if (args.length > 2)
	    {
		printf("--------------------------------------\n%8lu%8lu%8lu total",
		    l_total, w_total, c_total);
	    }

	    printf("--------------------------------------\n");

	    foreach (char[] word1; dictionary.keys.sort)
	    {
		printf("%3d %.*s\n", dictionary[word1], word1);
	    }
	    return 0;
	}
	

D Community

References

• The D Programming Language specification: www.digitalmars.com/d/
• D newsgroups: news.digitalmars.com
• Design By Contract: "Object-Oriented Software Construction" by Bertrand Meyer
• C++ Boost: www.boost.org

Acknowledgements

Bruce Eckel, Eric Engstrom, Jan Knepper, Helmut Leitner, Lubomir Litchev, Pavel Minayev, Paul Nash, Pat Nelson, Burton Radons, Tim Rentsch, Fabio Riccardi, Bob Taniguchi, John Whited, Matthew Wilson, Peter Zatloukal