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:
Here’s a version using the C++ standard library:
Here’s an idiomatic D version:
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
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.
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:
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
This allows verifying some assumption at compile time.
Systems code often makes assumptions about alignment or structure size or other things. With
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.
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:
You can use this much-less-bug-prone alternative:
A slice is nothing but a pointer/length pair with first-class syntactic support.
Compile Time Function Evaluation (CTFE)
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:
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.
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
Functional purity can be enforced. I’ve written about some of the benefits of the
SafeD is a subset of D that forbids risky language features like pointer typecasts and inline assembly. Code
@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
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?
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
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
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
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
directly to D code.