Change Log: 2.063

Eventually, they will be deprecated, and then will trigger an error. Such fields should now be changed to enum or static.

In a future release, a new behavior for them will be enabled:

Fields in an aggregate which are not static will always be addressable. This means they will occupy space in the object:

struct S
{
    // used to be implicitly static in 2.062, now warns. In a future release it will become non-static.
    immutable int[] arr = [1, 2];

    // ditto
    const int[] arr2 = [1, 2];
}

This means that code which accessed such declarations without the this reference will no longer compile. Additionally code which depended on the size of a structure with such fields will have to be fixed:

struct S
{
    immutable int[] arr = [1, 2];
}

void main()
{
    auto x = S.arr;  // becomes an error in a future release, 'arr' will require the 'this' reference.

    // S is size 1 in 2.062 and 2.063. In a future release this will change and the following static assert will pass.
    static assert(S.sizeof == size_t.sizeof + size_t.sizeof);  // ptr + length for the array
}

To make the field static again, simply use the static keyword. Alternatively make the field an enum to turn it into a manifest constant:

struct S
{
    static immutable int[] arr = [1, 2];
    enum arr2 = [1, 2];
}

Note however that manifest constants which are arrays are allocated on each usage, so you may prefer using static instead.

Rationale:

Making a field implicitly static based on whether it is const/immutable and has an initializer leads to confusion. The static keyword can be used to explicitly make any field static.

A qualified constructor is now invoked when a const/immutable/shared aggregate object is instantiated, respectively:

import std.stdio;

class C
{
    this()           { writeln("1"); }
    this() const     { writeln("2"); }
    this() immutable { writeln("3"); }
    this() shared    { writeln("4"); }
}

void main()
{
    auto a = new C;           // writes "1"
    auto b = new const C;     // writes "2"
    auto c = new immutable C; // writes "3"
    auto d = new shared C;    // writes "4"
}

This has the consequence that aggregates which have only immutable or shared constructors can no longer be used to instantiate mutable objects:

class C
{
    this() immutable { }
    this() shared { }
}

void main()
{
    auto c1 = new C;           // disallowed
    auto c2 = new immutable C; // ok
    auto c3 = new shared C;    // ok
}

On the other hand, aggregates which do not have shared or immutable constructors can no longer be used to construct shared or immutable objects, respectively:

class C
{
    this() { }
}

void main()
{
    auto c1 = new C;           // ok
    auto c2 = new immutable C; // disallowed
    auto c3 = new shared C;    // disallowed
}

However, if an aggregate has a pure constructor it can be used to construct an object with any type constructor:

class C
{
    this() pure { }
}

void main()
{
    auto c1 = new C;  // ok
    auto c2 = new immutable C;  // ok
    auto c3 = new shared C;  // ok
}

In earlier releases some struct members such as arrays would be bitwise-compared in a comparison operation. This has now been changed to be a structural comparison instead:

struct S
{
    char[] data;
}

void main ()
{
    auto s1 = S("foo".dup);
    auto s2 = S("foo".dup);

    assert(s1.data !is s2.data);  // both are unique data

    assert(s1 == s2);   // passes in 2.063
    assert(s1.data == s2.data);  // equivalent of above
}

If an opEquals function is not present the compiler rewrites the expression s1 == s2 to s1.tupleof == s2.tupleof. Comparing .tupleof expressions is also a feature new to D in the 2.063 release.

The right-hand-side of an array copy operation now requires using the slice syntax:

void main()
{
    int[][2] x;
    int[] y;
    int[] z;

    x[] = z;    // copies z (pointer + length) 2 times to x
    y[] = z;    // copies each element of z into y (compiler emits warning)
}

If the user intended to write such code they must use the slice syntax for both the source and target arrays:

void main()
{
    int[][2] x;
    int[] y;
    int[] z;

    y[] = z[];  // copies each element of z into y (no warnings)
}

Rationale:

The compiler will emit a warning to make the user aware that the copy operation is arbitrarily expensive.

A type can no longer be passed to a function as a value of that type:

T[] foo(T)(T t)
{
    return null;
}

void main()
{
    alias int Int;

    // used to work (only with an alias), now a compiler error
    alias typeof(foo(Int)) IntArray;
}

If the user wants to pass an argument of a certain type, they can use the .init property:

T[] foo(T)(T t)
{
    return null;
}

void main()
{
    alias typeof(foo(int.init)) IntArray;  // ok
}

Rationale:

Treating types as expressions in special contexts only leads to confusion. Instead, the .init property can be used for such purposes.

The index variable in a foreach range is now by default a value type:

void main()
{
    size_t count;
    foreach (n; 0 .. 10)
    {
        ++n;
        ++count;
    }
    assert(count == 10);  // passes
}

If the user wants to modify the index variable he must use the ref keyword:

void main()
{
    size_t count;
    foreach (ref n; 0 .. 10)
    {
        ++n;
        ++count;
    }
    assert(count == 5);
}

Rationale:

Making the index variable implicitly ref can introduce bugs that are hard to track down.

An associative array entry used to be default-initialized before assignment took place:

void main()
{
    int[int] aa;
    aa[1] = aa[1] + 1;   // no Error thrown in 2.062
    assert(aa[1] == 1);  // worked in 2.062
}

In 2.063, accessing an entry which does not exist will now throw a RangeError:

void main()
{
    int[int] aa;
    aa[1] = aa[1] + 1;   // RangeError thrown in 2.063
}

Rationale:

Default-initialization during assignment can be a source of bugs.

Method overrides no longer inherit constness of the base method:

class A
{
    void foo() const { }
}

class B : A
{
    // used to work in 2.062, now an error
    override void foo() { }  // note missing 'const'
}

If the user wants to override a const method he has to mark the overriden method as const:

class A
{
    void foo() const { }
}

class B : A
{
    override void foo() const { }  // ok
}

The feature allows introducing new overloads based on the constness of the method:

class A
{
    void foo() const { }
}

class B : A
{
    // introduces new overload (not override!)
    void foo() { }

    // if the above overload is introduced the user must either:
    // a: re-introduce the const overload to prevent function hijacking
    alias super.foo foo;  // without this you will get a compiler error

    // or b: provide a properly typed override:
    override void foo() const { }
}

The following code used to be allowed:

void f(int[] function() del)
{
    assert(!del());  // fails
}

typeof(null) g() { return null; }

void main()
{
    f(&g);
    f(() => null);
}

However the implicit conversion would end up generating wrong code. To work around this, make sure the return type is typed properly, or use (T[]).init in the return expression of a lambda expression:

void f(int[] function() del)
{
    assert(!del());  // passes
}

int[] g() { return null; }  // fixed return type

void main()
{
    f(&g);  // ok
    f(() => (int[]).init);  // ok
}

The Template This Parameter can now be used to infer the qualifier of this to member functions:

struct S
{
    void foo(this T)()
    {
    }
}

void main()
{
     immutable S s;
     s.foo();  // makes S.foo immutable
}

Array slices are no longer l-values. This means an address can no longer be taken of a slice, and slices cannot be passed by ref to functions:

void foo(ref int[] arr) { arr = new int[10]; }

void main()
{
    int[] arr;
    foo(arr);  // ok
    assert(arr.length == 10);

    foo(arr[]);  // disallowed in 2.063, the slice is an r-value
    auto ptr = &arr[1..2];  // disallowed in 2.063, cannot take address of r-value
}

To work around this you can make your function take an r-value if it doesn't need to reassign and resize the slice, but only needs to read or modify its contents. Otherwise, to accept both l-values and r-values you can make your function take its argument by auto ref:

void take(int[] arr) { }
void takeRef(ref int[] arr) { }
void takeAutoRef(T)(auto ref T[] arr) { }

void main()
{
    int[] arr = [1, 2, 3, 4];
    take(arr);          // ok
    takeRef(arr);       // ok
    takeAutoRef(arr);   // ok

    int[] arr2 = arr[1 .. 2];
    take(arr2);         // ok, arr2 is a variable
    takeRef(arr2);      // ditto
    takeAutoRef(arr2);  // ditto

    take(arr[1 .. 2]);         // ok
    takeRef(arr[1 .. 2]);      // error, cannot pass r-value by reference
    takeAutoRef(arr[1 .. 2]);  // ok
}

Rationale:

Passing slices by reference had no observable effect when reassigning or resizing such a slice at the call site, therefore such slices should by default be r-values. For example, the following code used to be allowed but is now a compile-time error:

void reAssign(ref int[] arr) { arr = new int[2]; }
void reSize(ref int[] arr)   { arr.length = 10; }

void main()
{
    int[] arr = [1, 2, 3, 4];

    reAssign(arr[0 .. 4]);  // reassigning has no observable effect at the call site
    assert(arr == [1, 2, 3, 4]);

    reSize(arr[0 .. 4]);    // resizing has no observable effect at the call site
    assert(arr.length == 4);
}

Accessing non-static fields used to be allowed in many contexts, but is now limited to only a few:

- offsetof, init, and other built-in properties are allowed:

struct S { int field; }

void main()
{
    auto a = S.field.offsetof;  // ok, statically known
    auto c = S.field.max;       // ditto
    auto d = S.field;           // disallowed, no `this` reference
}

- When invoking static methods of a non-static field:

struct Foo
{
    static struct Bar
    {
        static int get() { return 0; }
    }

    Bar bar;
}

void main()
{
    static assert(Foo.bar.get() == 0);  // ok, equivalent to `typeof(Foo.bar).get()`
}

- When accessing static fields implicitly using an alias this expression:

struct Foo
{
    static struct Bar
    {
        static int get() { return 0; }
    }

    Bar bar;
    alias bar this;
}

void main()
{
    static assert(Foo.get() == 0);  // ok, equivalent to 'typeof(Foo.bar).get()'
}

The implicit conversion of an array to a pointer was a deprecated feature:

void foo(int* p) { }

void main()
{
    int[] arr = [1, 2];
    foo(arr);   // ok if -d switch is used during compilation
}

This feature has now been completely removed. The workaround is to either use the .ptr property, or explicitly pass the pointer to the first element:

void foo(int* p) { }

void main()
{
    int[] arr = [1, 2];
    foo(arr);      // compile error
    foo(arr.ptr);  // ok
    foo(&arr[0]);  // ok
}

Expressions such as new for objects and arrays, and dup for arrays, can now be inferred to be unique. This allows the compiler to implicitly convert such an expression to immutable:

class C { }

void main()
{
    immutable int[] arr1 = new int[](3);   // ok
    immutable int[] arr2 = [1, 2, 3].dup;  // ok in 2.063
    immutable C[] arr3 = [new C, new C].dup;  // ok in 2.063
}

A static array of void could not be initialized in user-code:

void main()
{
    void[2] varr1;  // error in 2.062
    void[2] varr2 = (void[2]).init;  // error in 2.062
    void[2] varr3 = void;  // ok in 2.062
}

In 2.063, an explicit initializer can be used:

void main()
{
    void[2] varr1;  // still an error in 2.063
    void[2] varr2 = (void[2]).init;  // ok in 2.063
    void[2] varr3 = void;  // ok in 2.063
}

The .init property effectively zero-initializes the array.

Rationale:

The restriction has been lifted to allow generic code to use .init without having to specialize for static void arrays.

If an aggregate type has multiple invariants, the invariants' bodies will be merged into a single invariant function and will be run in sequence. Note that the code in one invariant cannot reference code or data in another invariant:

struct S
{
    int x;

    void foo() { }

    invariant()
    {
        int local;
        assert(x != 0);
    }

    invariant()
    {
        // local = 1;  // invariant does not have access to the other invariant's body
        assert(x % 2 == 0);
    }
}

void main()
{
    S s = S(2);
    s.foo();  // invoking public function triggers both invariants in sequence
}

If a function with some attributes instantiates a templated aggregate, it's member functions will infer those attributes:

struct S(T)
{
    T square(T x)
    {
        return x * x;
    }
}

void main() pure
{
    S!int s;  // S!int.square becomes pure and callable from main()
    assert(s.square(2) == 4);  // ok
}

In some cases the is expression required an identifier even when you didn't have a use for it:

void main()
{
    alias AA = string[int];

    static if (is(AA _ == V[K], V, K))
    {
        pragma(msg, _);  // prints string[int]
        pragma(msg, K);  // prints int
        pragma(msg, V);  // prints string
    }
}

The identifier is no longer required, so the above can be rewritten to:

void main()
{
    alias AA = string[int];

    static if (is(AA == V[K], V, K))
    {
        pragma(msg, AA); // prints string[int]
        pragma(msg, K);  // prints int
        pragma(msg, V);  // prints string
    }
}

In some contexts the compiler knows the size of a dynamic array or of a slice of an array. In such a case the compiler will allow an implicit conversion to a static array of the same size:

void foo(int[4] x) { }

void main()
{
    int[] arr = [1, 2, 3, 4, 5, 6, 7, 8];
    foo(arr[0 .. 4]);  // ok
}

Another example, where a string is converted to a reference to a static array:

string str = "aaaabbbbccccdddd";

void foo(ref const(char)[16] buf)
{
    assert(buf.ptr is str.ptr);
}

void main()
{
    foo(str[0..16]);  // ok
}

Limitations:

- This feature does not yet work with complex expressions where it might be reasonable to assume the size of a slice:

void foo(int[4] x) { }

void main()
{
    int[] arr = [1, 2, 3, 4, 5, 6, 7, 8];
    foreach (i; 0 .. 4)
    {
        foo(arr[i .. i + 4]);  // not yet supported
    }
}

You can now void-initialize a tuple variable:

template Tuple(T...)
{
    alias T Tuple;
}

void main()
{
    Tuple!(int, int) tup1 = void;  // ok
}

Upon such initialization the values in the tuple are undetermined.

Template constraints used to be allowed only before the inheritance list, leading to code where the inheritance list could be hard to spot:

class Foo(T1, T2)
    if (is(T1 == int) && is(T2 == string)) : Base
{
}

This restriction has been lifted, so you can now write:

class Foo(T1, T2) : Base
    if (is(T1 == int) && is(T2 == string))
{
}

Example:

struct Tuple(T...) { T field; alias field this; }

void main()
{
    auto tup1 = Tuple!(int, int)(1, 2);
    auto tup2 = Tuple!(int, int)(1, 2);
    auto tup3 = Tuple!(int, int)(1, 3);

    assert(tup1 == tup2);  // works since 2.063
    assert(tup1 != tup3);  // works since 2.063
}

This also means you can now compare ParameterStorageClassTuple instances from std.traits:

import std.traits;

void func1(ref int x, ref int y) { }
void func2(ref float x, ref float y) { }

void main()
{
    alias Storages = ParameterStorageClassTuple;
    assert(Storages!func1 == Storages!func2);
}

In addition to that, builtin .tupleof expressions can be used to easily compare fields of an aggregate:

struct S
{
    char[] a, b;

    // Implements equality test against another instance of this type.
    bool opEquals(S rhs) { return this.tupleof == rhs.tupleof; }
}

void main()
{
    S s1 = S("a".dup, "b".dup);
    S s2 = S("a".dup, "b".dup);
    assert(s1 == s2);
}

This also allows you to implement a structural equality test against an instance of a different type:

struct S1
{
    char[] a, b;

    // Implements a structural equality test against any other type T
    bool opEquals(T)(T rhs) { return this.tupleof == rhs.tupleof; }
}

struct S2
{
    string x, y;
}

void main()
{
    auto s1 = S1("123".dup, "456".dup);
    auto s2 = S2("123", "456");
    assert(s1 == s2);
}

Since tuples can be sliced you can use this feature to compare a subset of tuples:

struct S
{
    int a, b, c, d, e;

    bool opEquals(S rhs)
    {
        // compares a, b, d, and e
        return this.tupleof[0..2] == rhs.tupleof[0..2] &&
               this.tupleof[3..5] == rhs.tupleof[3..5];
    }
}

void main()
{
    S s1 = S(1, 2, 0, 3, 4);
    S s2 = S(1, 2, 1, 3, 4);
    assert(s1 == s2);
}

You can now initialize a field in a const constructor even if such a field already has an initializer:

struct S
{
    bool field = true;

    this(int v) const
    {
        field = false;  // ok
    }
}

The new isNested trait allows you to discover whether an aggregate or function contains a context pointer:

void main()
{
    int x;

    struct S1 { void f() { x++; } }
    static struct S2 { }

    void f1() { x++; }
    static void f2() { }

    static assert(__traits(isNested, S1));
    static assert(__traits(isNested, f1));
    static assert(!__traits(isNested, S2));
    static assert(!__traits(isNested, f2));
}

Functions that are made available through a local import are now picked up when using Uniform Function Call Syntax:

module foo;
string concat(string arg1, string arg2) { return arg1 ~ arg2; }

module test;
void main()
{
    import foo;
    assert("foo".concat("bar") == "foobar");  // UFCS now works
}

This feature also works for imports within aggregates. Note that local imports have a higher precedence than module-scoped imports.

A new set of special keywords were added. Together with __FILE__ and __LINE__ they form a complete feature set that is useful in debugging code:

module test;
import std.stdio;

void test(string file = __FILE__, size_t line = __LINE__, string mod = __MODULE__,
          string func = __FUNCTION__, string pretty = __PRETTY_FUNCTION__)
{
    writefln("file: '%s', line: '%s', module: '%s',\nfunction: '%s', pretty function: '%s'",
             file, line, mod, func, pretty);
}

int main(string[] args)
{
    test();
    return 0;
}

The above will output:

file: 'test.d', line: '13', module: 'test',
function: 'test.main', pretty function: 'int test.main(string[] args)'

module test;

/// sum function
deprecated int sum(int x, int y) { return x + y; }

By default the macro expands to its argument. It can be overriden by the user, for example:

macros.ddoc:

DEPRECATED=<del>$0</del>

The above ddoc file can then be used when the documentation is being generated:

$ dmd -D -o- test.d macros.ddoc

Documented unittests which follow any symbol declarations are now used to generate example sections for the symbol when generating DDOC documentation. Example:

/// sum function
int sum(int x, int y) { return x + y; }

///
unittest
{
    assert(sum(2, 2) == 4);
}

The body of the unittest will be part of the documentation of the sum function. This allows the implementor of the function to keep their examples always up-to-date.

For more information, see the documentation page of documented unittests.

The -main switch is primarily useful when unittesting libraries:

module test;

int sum(int a, int b) { return a + b; }
unittest
{
    assert(sum(2, 2) == 4);
}

The above library would need a main() function for the unittests to run, and -main can be used for this purpose:

$ dmd -unittest -main -run test.d

The -cov switch now has an optional percentage setting which makes the executable emit an error when the coverage doesn't meet the specified requirement:

module test;

void test1() { int x = 5; }
void test2() { int x = 5; }
void test3() { int x = 5; }

void main()
{
    test1();
    test2();
}

Example of coverage testing:

$ dmd -cov=90 test.d
$ test
Error: test.d is 80% covered, less than required 90%

The new pragma(mangle, ...) directive allows you to set a custom mangling for any symbol:

pragma(mangle, "module") extern(C) void module_();

The above allows linking to a C function named "module", which ordinarily we wouldn't be able to link to directly since "module" is a reserved D keyword.

User-code which used the std.traits.ReturnType trait to retrieve the type of a scoped call will have to be changed to use the typeof operator instead:

class A
{
    this() {}
    this(int) {}
}

class B
{
    // ReturnType!(scoped!A) a;  // disallowed in 2.063
    typeof(scoped!A()) a;        // rewritten, compiles in 2.063

    this()
    {
        a = scoped!A(1);  // would not compile in 2.062, but works with syntax used for 2.063
    }
}

The reason for this change is that the ReturnType trait would retrieve the wrong type when a class had multiple constructors, and this would cause initializing the field to fail.

Another benefit of the new implementation is that scoped can now be aliased for usability purposes:

class A
{
    this(int) { }
}

void main()
{
    alias scoped!A scopeA;
    auto a = scopeA(1);
}

The new std.process module introduces functionality for invoking processes with custom pipe redirection, the ability to wait for processes to finish, and the ability to kill processes. The full list of features can be found in the std.process documentation.

Example code:

void main(string[] args)
{
    bool flag = true;
    getopt(args, &flag);
}

When invoked via --flag=false, it will set flag to false.

It is now easier to send a message from a child thread to its owner thread. Simply use the ownerTid property to get the owner thread's Tid identifier:

void fun()
{
    string res = receiveOnly!string();
    assert(res == "Main calling");

    ownerTid.send("Child responding");  // new
}

void main()
{
    auto child = spawn(&fun);
    child.send("Main calling");

    string res = receiveOnly!string();
    assert(res == "Child responding");
}

If the owner thread has exited, accessing ownerTid from any of its child threads will throw a TidMissingException.