Sircmpwn (the main developer behind the Sway Wayland compositor) recently
wrote a blog post about how he thinks Rust is not a good C replacement.
I don’t know if he’d like the D programming language either, but it’s become a C
replacement for me.

My C to D Story

My story is like a lot of systems programmers’ stories. At one time, C was my go-to language for most
programming. One day I realised that most of my C programs kept reimplementing things from C++: dynamic arrays,
better strings, polymorphic classes, etc. So I tried using C++ instead, and at first I loved it. RAII and classes
and generics made programming fun again. Even better was the promise that if I read all these books on C++, and
learned to master things like template metaprogramming, I’d become an almighty god of systems programming and my
code would be amazing. But learning more eventually had the opposite effect: (in hindsight) my code actually got
worse, and I fell out of love. I remember reading Scott Meyer’s Effective C++ and realising it was really more
about ineffective C++ — and that most of my C++ code until then was broken. Let’s face it: C might be
fiddly to use, but it has a kind of elegance, and “elegant” is rarely a word you hear when C++ is involved.

Apparently, a lot of ex-C C++ programmers end up going back to C. In my case, I discovered D. It’s also not
perfect, but I use it because it feels to me a lot more like the C += 1 that C++ was meant to be.
Here’s an example that’s very superficial, but I think is representative. Take this simple C program:

#include 

int main()
{
    printf("1 + 1 = %d!n", 1 + 1);
    return 0;
}

Here’s a version using the C++ standard library:

#include 

int main()
{
    std::cout << "1 + 1 = " << 1 + 1 << "!" << std::endl;
    return 0;
}

Here’s an idiomatic D version:

import std.stdio;

void main()
{
    writef("1 + 1 = %d!n", 1 + 1);
}

As I said, it’s a superficial example, but I think it shows a general difference in philosophy between C++ and
D. (If I wanted to make the difference even clearer, I’d use an example that needed iomanip in
C++.)

This article about C++
member function pointers happens to also be a good explanation of the origins of D. It’s a good read if
you’re a programming language nerd, but here’s my TL;DR for everyone else: C++ member function pointers are
supposed to feel like a low-level feature (like normal function pointers are), but the complexity and diversity
of implementations means they’re really high level. The complexity of the implementations is because of the
subtleties of the rules about what you can do with them. The author explains the implementations from several C++
compilers, including what’s “easily [his] favorite implementation”: the elegantly simple Digital Mars C++
implementation. (“Why doesn’t everyone else do it this way?”) The DMC compiler was written by Walter Bright, who
invented D.

D has classes and templates and other core features of C++, but designed by someone who has spent a heck of a
lot of time thinking about the C++ spec and how things could be simpler. Walter once said that his experiences
implementing C++ templates made him consider not including them in D at all, until he realised they didn’t need
to be so complex.

Here’s a quick tour of D from the point of view of incrementally improving C.

-betterC

D compilers support a -betterC switch that disables the D runtime and all high-level features that depend on it. The
example C code above can be translated directly into betterC:

import core.stdc.stdio;

extern(C):

int main()
{
    printf("1 + 1 = %d!n", 1 + 1);
    return 0;
}

$ dmd -betterC example.d
$ ./example
1 + 1 = 2!

The resulting binary looks a lot like the equivalent C binary. In fact, if you rewrote a C library in betterC,
it could still link to code that had been compiled against the C version, and work without changes. Walter Bright
wrote a good article walking through all the changes needed to convert a real C
program to betterC.

You don’t actually need the -betterC switch just to write C-like code in D. It’s only needed in
special cases where you simply can’t have the D runtime. But let me point out some of my favourite D features
that still work with -betterC.

static assert()

This allows verifying some assumption at compile time.

static assert(kNumInducers < 16);

Systems code often makes assumptions about alignment or structure size or other things. With static
assert, it’s possible to not only document these assumptions, but trigger a compilation error if someone
breaks them by adding a struct member or something.

Slices

Typical C code is full of pointer/length pairs, and it’s a common bug for them to go out of sync. Slices are a
simple and super-useful abstraction for a range of memory defined by a pointer and length. Instead of code like
this:

buffer_p += offset;
buffer_len -= offset;  // Got to update both

You can use this much-less-bug-prone alternative:

buffer = buffer[offset..$];

A slice is nothing but a pointer/length pair with first-class syntactic support.

Compile Time Function Evaluation (CTFE)

Many functions can be evaluated at compile
time.

long factorial(int n) pure
{
    assert (n >= 0 && n <= 20);
    long ret = 1;
    foreach (j; 2..n+1) ret *= j;
    return ret;
}

// Statically allocated array
// Size is calculated at compile time
Permutation[factorial(kNumThings)] permutation_table;

scope Guards

Code in one part of a function is often coupled to cleanup code in a later part. Failing to match this code up
correctly is another common source of bugs (especially when multiple control flow paths are involved). D’s scope
guards make it simple to get this stuff right:

p = malloc(128);
// free() will be called when the current scope exits
scope (exit) free(p);
// Put whatever if statements, or loops, or early returns you like here

You can even have multiple scope guards in a scope, or have nested scopes. The cleanup routines will be called
when needed, in the right order.

D also supports RAII using struct destructors.

const and immutable

It’s a popular myth that const in C and C++ is useful for compiler optimisations. Walter Bright
has complained that every time he thought of a new const-based optimisation for C++, he eventually
discovered it didn’t work in real code. So he made some changes to const semantics for D, and added
immutable. You can read more in the D
const FAQ.

pure

Functional purity can be enforced. I’ve written about some of the benefits of the pure keyword
before.

@safe

SafeD is a subset of D that forbids risky language features like pointer typecasts and inline assembly. Code
marked @safe is enforced by the compiler to not use these features, so that risky code can be
limited to the small percentage of the application that needs it. You can read more about SafeD in this
article.

Metaprogramming

Like I hinted earlier, metaprogramming has got a bad reputation among some C++ programmers. But D has the advantage of making metaprogramming less
interesting, so D programmers tend to just do it when it’s useful, and not as a fun puzzle.

D has great support for compile-time reflection. In most
cases, compile-time reflection can solve the same problems as run-time reflection, but with compile-time
guarantees. Compile-time reflection can also be used to implement run-time reflection where needed.

Need the names of an enumerated type as an array?

enum State
{
    stopped,
    starting,
    running,
    stopping,
}

string[] state_names = [__traits(allMembers, State)];

Thanks to D’s metaprogramming, the standard library has many nice, typesafe tools, like this compile-time checked bit flag enum.

I’ve written more about using metaprogramming in
-betterC code.

No Preprocessor

Okay, this a non-feature as a feature, but D has no equivalent to C’s preprocessor. All its sane use-cases are
replaced with native language features, like manifest constants and templates. That includes proper modules
support, which means D can break free of the limitations of that old #include hack.

Normal D

C-like D code can be written and compiled as normal D code without the -betterC switch. The
difference is that normal D code is linked to the D runtime, which supports higher-level features, the most
obvious ones being garbage collection and object-oriented classes. Some people have confused the D runtime with
something like the Java virtual machine, so I once wrote an
article explaining exactly what it is (spoiler: it’s like the C and C++ runtimes, but with more
features).

Even with the runtime, compiled D is not much different from compiled C++. Sometimes I like to write throwaway
code to, say, experiment with a new Linux system call or something. I used to think the best language for that is
plain old C, but now I always use D.

D doesn’t natively support #includeing C code, but for nice APIs that don’t have a lot of
preprocessor craziness (like most of Linux) I usually just write ad-hoc bindings. Many popular C libraries have maintained D bindings,
which can be found in the Dub registry, or in the Derelict project, or in the newer BindBC project. There are also tools for automated bindings, including the
awesome dpp tool that brings #include support
directly to D code.