Memory safety is an important issue in software development. Systems languages like C, C++ and D offer a number of opportunities for programmer mistakes to open the door to memory corruption during program execution, possibly leading to critical system failures, or making it easier for those with nefarious intent to achieve their goals. Other languages, such as Java and C#, have built-in features intended to minimize this risk and increase memory safety.

While D is a systems language, it includes some features by default that aim to increase memory safety. Arrays all carry around their length, meaning it's always easy to determine exactly how many elements an array contains. This is further enhanced through the bounds-checking of all array accesses, though this can be disabled on the command line; a systems programming language needs to allow performance to be a priority when it has to be. Still, D gives you that same proverbial gun that C and C++ do; you're less likely to blow off your entire foot with it, but that's not the whole story.

There is a subset of D that allows for a high degree of memory safety. This subset, commonly referred to as SafeD, allows programmers to opt-in in order to avoid common mistakes that can lead to memory corruption. This is achieved by annotating code with the attributes @safe, @trusted, and @system.

By default, all D code is @system. This means it is possible for the programmer to take advantage of the full power of the language. Memory safety is enforced by applying the @safe attribute. Like other attributes, it can be applied directly to functions, or to entire blocks of code using colons or braces.

module my_safe_module;
// Enable SafeD
@safe:
void thisFunctionIsSafe() {}
// Go back to the default
@system:
void thisFunctionIsNotSafe() {}
void anotherSafeFunction() @safe {}

@safe functions come with a few restrictions on the sort of code they can contain. For example, pointer arithmetic is forbidden, casts from pointers to non-pointers are forbidden, taking the address of a local variable is not allowed, const, immutable, and shared cannot be cast away, all array accesses are bounds-checked even when the command line switch -release is given to the compiler (though –boundscheck=off will disable it completely), and more. Another important component of SafeD is that @safe functions can only call other functions that are annotated with @safe or @trusted.

The @trusted attribute presents a safe interface, but the compiler does not attempt to verify that the implementation meets the restrictions of @safe. In other words, functions marked as @trusted can serve as a bridge between safe and unsafe code. It is incumbent upon the programmer to verify that @trusted code isn't doing anything that can corrupt memory. For example, taking the address of a local variable isn't an unsafe operation in and of itself; @safe prohibits it solely because it's the easiest and cheapest way to prevent local addresses from escaping, so any function where it is necessary to do this can be safely marked with @trusted (as long as the programmer verifies that the address doesn't escape). The same can be said of pointer arithmetic; as long as the programmer verifies that it stays within the bounds of the block of memory to which the pointer points, the code can be considered @trusted. Ultimately, @trusted serves as a marker indicating that maintainers need to pay extra attention when modifying this code and clients can trust that nothing untoward is going on.

Fully understanding and responsibly using SafeD requires an intimate knowledge of D and any peripheral libraries used in a project. Moreover, not all D programmers make use of these features, so there are a number of libraries in the D ecosystem where no consideration has been given to the SafeD subset, limiting the range of libraries available for those who do choose to use it. That said, as more D programmers take the plunge to understand and use it, it will become less of an issue. That makes it worthwhile to explore at some point during your journey with D. For more about SafeD, refer to http://dlang.org/function.html#function-safety.