Editing D (programming language) (section)

==Features==
D is not [[Source-code compatibility|source-compatible]] with C and C++ source code in general. However, any code that is legal in both C/C++ and D should behave in the same way.

Like C++, D has [[closure (computer science)|closures]], [[anonymous functions]], [[compile-time function execution]], [[design by contract]], ranges, built-in container iteration concepts, and [[type inference]]. D's declaration, statement and expression [[syntax]]es also closely match those of C++.

Unlike C++, D also implements [[garbage collection (computer science)|garbage collection]], [[first-class citizen|first class]] [[array data type|arrays]] (<code>std::array</code> in C++ are technically not first class), [[array slicing]], [[nested function]]s and [[lazy evaluation]]. D uses Java-style [[multiple inheritance|single inheritance]] with [[interface (computer science)|interfaces]] and [[mixin]]s rather than C++-style [[multiple inheritance]].

D is a systems programming language. Like C++, and unlike application languages such as [[Java (programming language)|Java]] and [[C Sharp (programming language)|C#]], D supports [[low-level programming language|low-level programming]], including [[inline assembler]]. Inline assembler allows programmers to enter machine-specific [[assembly language|assembly code]] within standard D code. System programmers use this method to access the low-level features of the [[central processing unit|processor]] that are needed to run programs that interface directly with the underlying [[computer hardware|hardware]], such as [[operating system]]s and [[device driver]]s. Low-level programming is also used to write higher [[Computer performance|performance]] code than would be produced by a [[compiler]].

D supports [[function overloading]] and [[operator overloading]]. Symbols ([[Function (computer programming)|functions]], [[Variable (computer science)|variables]], [[Class (computer programming)|classes]]) can be declared in any order; [[forward declaration]]s are not needed.

In D, text character strings are arrays of characters, and arrays in D are bounds-checked.<ref>{{cite web |url=https://digitalmars.com/d/1.0/cppstrings.html |title=D Strings vs C++ Strings |publisher=Digital Mars |date=2012}}</ref> D has [[First-class citizen|first class types]] for complex and imaginary numbers.<ref>{{cite web|date=2012|title=D Complex Types and C++ std::complex|url=https://digitalmars.com/d/1.0/cppcomplex.html|url-status=live|access-date=4 November 2021|website=[[Digital Mars]]|archive-url=https://web.archive.org/web/20080113085617/http://www.digitalmars.com:80/d/1.0/cppcomplex.html |archive-date=13 January 2008}}</ref>

===Programming paradigms===
D supports five main [[programming paradigm]]s:
* [[Concurrent programming language|Concurrent]] ([[actor model]])
* [[Object-oriented programming|Object-oriented]]
* [[Imperative programming|Imperative]]
* [[Functional programming|Functional]]
* [[Metaprogramming]]

====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, unlike C, D's [[foreach|<code>foreach</code>]] loop construct allows looping over a collection. D also allows [[nested function]]s, which are functions that are declared inside another function, and which may access the enclosing function's [[local variable]]s.

<syntaxhighlight lang="D">
import std.stdio;

void main() {
   int multiplier = 10;
   int scaled(int x) {
      return x * multiplier;
   }

   foreach (i; 0 .. 10) {
      writefln("Hello, world %d! scaled = %d", i, scaled(i));
   }
}
</syntaxhighlight>

====Object-oriented====
Object-oriented programming in D is based on a single [[Inheritance (object-oriented programming)|inheritance]] hierarchy, with all classes derived from class Object. D does not support multiple inheritance; instead, it uses Java-style [[interface (Java)|interfaces]], which are comparable to C++'s pure abstract classes, and [[mixin]]s, which separate 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 [[Covariance and contravariance (computer science)|covariant types]] for return types of overridden methods.

D supports type forwarding, as well as optional custom [[dynamic dispatch]].

Classes (and interfaces) in D can contain [[Class invariant|invariants]] which are automatically checked before and after entry to public methods, in accordance with the [[design by contract]] methodology.

Many aspects of classes (and structs) can be [[Type introspection|introspected]] automatically at compile time (a form of [[reflective programming]] (reflection) using <code>type traits</code>) and at run time (RTTI / <code>TypeInfo</code>), to facilitate generic code or automatic code generation (usually using compile-time techniques).

====Functional====
D supports [[functional programming]] features such as [[anonymous function|function literals]], [[Closure (computer science)|closures]], recursively-immutable objects and the use of [[higher-order function]]s. There are two syntaxes for anonymous functions, including a multiple-statement form and a "shorthand" single-expression notation:<ref name="short">{{cite web |title=Expressions |url=http://dlang.org/expression.html#Lambda |publisher=Digital Mars |access-date=27 December 2012}}</ref>

<syntaxhighlight lang="D">
int function(int) g;
g = (x) { return x * x; }; // longhand
g = (x) => x * x;          // shorthand
</syntaxhighlight>

There are two built-in types for function literals, <code>function</code>, which is simply a pointer to a stack-allocated function, and <code>delegate</code>, which also includes a pointer to the relevant [[stack frame]], the surrounding ‘environment’, which contains the current local variables. Type inference may be used with an anonymous function, in which case the compiler creates a <code>delegate</code> 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 (data structure)|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 <code>pure</code> and <code>nothrow</code> 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 (higher-order function)|map]], [[filter (higher-order function)|filter]], and [[fold (higher-order function)|reduce]] are available through the standard library modules <code>std.functional</code> and <code>std.algorithm</code>.

<syntaxhighlight lang="D">
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
}
</syntaxhighlight>

Alternatively, the above function compositions can be expressed using Uniform function call syntax (UFCS) for more natural left-to-right reading:

<syntaxhighlight lang="D">
    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);
</syntaxhighlight>

====Parallelism====
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.

<syntaxhighlight lang="D">
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);
    }
}
</syntaxhighlight>

<code>iota(11).parallel</code> is equivalent to <code>std.parallelism.parallel(iota(11))</code> by using UFCS.

The same module also supports <code>taskPool</code> which can be used for dynamic creation of parallel tasks, as well as map-filter-reduce and fold style operations on ranges (and arrays), which is useful when combined with functional operations. <code>std.algorithm.map</code> returns a lazily evaluated range rather than an array. This way, the elements are computed by each worker task in parallel automatically.

<syntaxhighlight lang="D">
import std.stdio : writeln;
import std.algorithm : map;
import std.range : iota;
import std.parallelism : taskPool;

/* 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
 */
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);
}
</syntaxhighlight>

====Concurrency====
Concurrency is fully implemented in the library, and it does not require 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.

<syntaxhighlight lang="D">
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));
}
</syntaxhighlight>

====Metaprogramming====
[[Metaprogramming]] is supported through templates, compile-time function execution, [[tuple]]s, 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:

<syntaxhighlight lang="D">
ulong factorial(ulong n) {
    if (n < 2)
        return 1;
    else
        return n * factorial(n-1);
}
</syntaxhighlight>

Here, the use of <code>static if</code>, 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:

<syntaxhighlight lang="D">
template Factorial(ulong n) {
    static if (n < 2)
        enum Factorial = 1;
    else
        enum Factorial = n * Factorial!(n-1);
}
</syntaxhighlight>

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 [[type inference|infers their types]] from the right-hand sides of assignments:

<syntaxhighlight lang="D">
enum fact_7 = Factorial!(7);
</syntaxhighlight>

This is an example of [[compile-time function execution]] (CTFE). Ordinary functions may be used in constant, compile-time expressions provided they meet certain criteria:

<syntaxhighlight lang="D">
enum fact_9 = factorial(9);
</syntaxhighlight>

The <code>std.string.format</code> function performs [[printf|<code>printf</code>]]-like data formatting (also at compile-time, through CTFE), and the "msg" [[Directive (programming)|pragma]] displays the result at compile time:

<syntaxhighlight lang="D">
import std.string : format;
pragma(msg, format("7! = %s", fact_7));
pragma(msg, format("9! = %s", fact_9));
</syntaxhighlight>

String mixins, combined with compile-time function execution, allow for the generation of D code using string operations at compile time. This can be used to parse [[domain-specific language]]s, which will be compiled as part of the program:

<syntaxhighlight lang="D">
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")));
}
</syntaxhighlight>

===Memory management===
Memory is usually managed with [[garbage collection (computer science)|garbage collection]], but specific objects may be finalized immediately when they go out of scope. This is what the majority of programs and libraries written in D use.

In case more control over memory layout and better performance is needed, explicit memory management is possible using the [[operator overloading|overloaded operator]] <code>new</code>, by calling [[C (programming language)|C]]'s [[malloc|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.<ref>{{cite web |title=std.gc |url=http://www.digitalmars.com/d/1.0/phobos/std_gc.html |work=D Programming Language 1.0 |publisher=Digital Mars |access-date=6 July 2010}}</ref> The manual gives many examples of how to implement different highly optimized memory management schemes for when garbage collection is inadequate in a program.<ref>{{cite web |url=http://dlang.org/memory.html |title=Memory Management |publisher=Digital Mars |work=D Programming Language 2.0 |access-date=17 February 2012}}</ref>

In functions, <code>struct</code> instances are by default allocated on the stack, while <code>class</code> instances 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 <code>std.typecons.scoped</code>, or by using <code>new</code> for structs and assigning to a pointer instead of a value-based variable.<ref name="dlang.org">{{cite web |title=Go Your Own Way (Part One: The Stack) |url=https://dlang.org/blog/2017/07/07/go-your-own-way-part-one-the-stack/ |website=The D Blog |date=7 July 2017 |access-date=2020-05-07}}</ref>

In functions, static arrays (of known size) are allocated on the stack. For dynamic arrays, one can use the <code>core.stdc.stdlib.alloca</code> function (similar to <code>alloca</code> in C), to allocate memory on the 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).<ref name="dlang.org"/>

A <code>scope</code> 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.<ref>{{cite web |title=Attributes - D Programming Language |url=https://dlang.org/spec/attribute.html#scope |website=dlang.org |access-date=2020-05-07}}</ref>

<code>std.experimental.allocator</code> contains a modular and composable allocator templates, to create custom high performance allocators for special use cases.<ref>{{cite web |title=std.experimental.allocator - D Programming Language |url=https://dlang.org/phobos/std_experimental_allocator.html |website=dlang.org |access-date=2020-05-07}}</ref>

===SafeD===
SafeD<ref name="SafeD">{{cite web |title=SafeD – D Programming Language |url=http://dlang.org/safed.html |author=Bartosz Milewski |access-date=17 July 2014}}</ref>
is the name given to the subset of D that can be guaranteed to be [[Memory safety|memory safe]]. Functions marked <code>@safe</code> are checked at compile time to ensure that they do not use any features, such as pointer arithmetic and unchecked casts, that could result in corruption of memory. Any other functions called must also be marked as <code>@safe</code> or <code>@trusted</code>. Functions can be marked <code>@trusted</code> 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.<ref>{{cite web |title=How to Write @trusted Code in D |url=https://dlang.org/blog/2016/09/28/how-to-write-trusted-code-in-d/ |author=Steven Schveighoffer |date=28 September 2016 |access-date=4 January 2018}}</ref>

====Scope lifetime safety====
Initially under the banners of DIP1000<ref>{{Cite web|url=https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md|title=Scoped Pointers|website=[[GitHub]]|date=3 April 2020}}</ref> and DIP25<ref>{{Cite web|url=https://wiki.dlang.org/DIP25|title=Sealed References}}</ref> (now part of the language specification<ref>{{Cite web|url=https://dlang.org/spec/function.html#return-scope-parameters|title=D Language Specification: Functions - Return Scope Parameters}}</ref>), 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<ref>{{Cite web|url=https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/|title=Ownership and Borrowing in D|date=15 July 2019}}</ref> (influenced by ideas from [[Rust (programming language)|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:
<syntaxhighlight lang="D">
@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; // The lifetime of "bad" only extends to the scope in which it is defined.
        *rad = bad;   // This is valid.
        rad = &bad;   // The lifetime of rad is longer than bad, hence this is not valid.
    }
}
</syntaxhighlight>

====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 language standard dictates the following behaviour:<ref>{{Cite web|url=https://dlang.org/spec/function.html#param-storage|title=D Language Specification: Functions - Function Parameter Storage Classes}}</ref>
{| class="wikitable"
|+
!Storage Class
!Behaviour (and constraints to) of a parameter with the storage class
|-
|''scope''
|References in the parameter cannot be escaped. Ignored for parameters with no references
|-
|''return''
|Parameter may be returned or copied to the first parameter, but otherwise does not escape from the function. Such copies are required not to outlive the argument(s) they were derived from. Ignored for parameters with no references
|}
An annotated example is given below.<syntaxhighlight lang="D">
@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 variable gp.
     gp = q; // Error, q escapes to global variable gp.
     gp = r; // OK.

     thorin(p); // OK, p does not escape thorin().
     thorin(q); // OK.
     thorin(r); // OK.

     gloin(p); // Error, p escapes gloin().
     gloin(q); // Error, q escapes gloin().
     gloin(r); // OK that r escapes gloin().

     return p; // OK.
     return q; // Error, cannot return 'scope' q.
     return r; // OK.
}
</syntaxhighlight>

===Interaction with other systems===
[[C (programming language)|C]]'s [[application binary interface|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 [[Language binding|bindings]] are available for many popular C libraries. Additionally, C's standard [[library (computer science)|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, the GDC compiler allows to link and intermix C, C++, and other supported language codes such as Objective-C. 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 [[Callback (computer programming)|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, [[union type|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 (programming language)|Python]],<ref>{{cite web |title=PyD |website=[[GitHub]] |url=https://github.com/ariovistus/pyd |access-date=2020-05-07 |date=7 May 2020}}</ref> [[Lua (programming language)|Lua]]<ref>{{cite web |last1=Parker |first1=Mike |title=Package derelict-lua on DUB |url=https://code.dlang.org/packages/derelict-lua |website=DUB Package Registry |access-date=2020-05-07}}</ref><ref>{{cite web |last1=Parker |first1=Mike |title=Package bindbc-lua on DUB |url=https://code.dlang.org/packages/bindbc-lua |website=DUB Package Registry |access-date=2020-05-07}}</ref> and other languages, often using compile-time code generation and compile-time type reflection methods.

====Interaction with C++ code====

For D code marked as <code>extern(C++)</code>, the following features are specified:

* The name mangling conventions shall match those of C++ on the target.
* For function calls, the ABI shall be equivalent.
* The vtable shall be matched up to single inheritance (the only level supported by the D language specification).

C++ namespaces are used via the syntax <code>extern(C++, namespace)</code> where ''namespace'' is the name of the C++ namespace.

=====An example of C++ interoperation=====
'''The C++ side'''
<syntaxhighlight lang="C++">
import std;

class Base {
    public:
        virtual void print3i(int a, int b, int c) = 0;
};

class Derived : public Base {
    public:
        int field;
        Derived(int field): 
            field(field) {}

        void print3i(int a, int b, int c) {
            std::println("a = {}", a);
            std::println("b = {}", b);
            std::println("c = {}", c);
        }

        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;
}
</syntaxhighlight>

'''The D side'''
<syntaxhighlight lang="D">
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);
}
</syntaxhighlight>

===Better C===
The D programming language has an official subset known as "{{nowrap|Better C}}".<ref name=":0">{{Cite web|url=https://dlang.org/spec/betterc.html|title=Better C}}</ref> 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, {{nowrap|Better C}} may only call into D code compiled under the same flag (and linked code other than D) but code compiled without the {{nowrap|Better C}} 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.

====Features included in Better C====
* Unrestricted use of compile-time features (for example, D's dynamic allocation features can be used at compile time to pre-allocate D data)
* Full metaprogramming facilities
* Nested functions, nested structs, delegates and lambdas
* Member functions, constructors, destructors, operating overloading, etc.
* The full module system
* Array slicing, and array bounds checking
* RAII
* '''{{not a typo|scope(exit)}}'''
* Memory safety protections
* Interfacing with C++
* COM classes and C++ classes
* '''assert''' failures are directed to the C runtime library
* '''switch''' with strings
* '''final switch'''
* '''unittest''' blocks
* '''printf''' format validation

====Features excluded from Better C====
* Garbage collection
* TypeInfo and ModuleInfo
* Built-in threading (e.g. <code>core.thread</code>)
* Dynamic arrays (though slices of static arrays work) and associative arrays
* Exceptions
* ''synchronized'' and <code>core.sync</code>
* Static module constructors or destructors