Change Log: 2.081.0

Class allocators and deallocators have been planned for deprecation for years. Starting with this release the following code will emit deprecation messages.

class C
{
    new(size_t size)         // deprecation message
    {
        return malloc(size);
    }

    delete(void* obj)        // deprecation message
    {
        free(obj);
    }
}

See the Deprecated Features for more information.

Many alternatives for class allocators/deallcators exist. Among them is the generic std.experimental.allocator.make and std.experimental.allocator.dispose from the allocator package. For other alternatives, see the recent article about memory allocation on the DBlog and the D Wiki memory management article.

Users have leveraged allocators in order to disable GC allocation, as illustrated in the following example:

class C
{
    @disable new(size_t size);
}

void main()
{
    auto c = new C();  // Error: allocator `new` is not callable because it is annotated with `@disable`
}

That idiom will remain, but has been enhanced with this release to no longer require the size_t argument. That is, starting with this release, the following syntax is also permitted:

class C
{
    @disable new();
}

void main()
{
    auto c = new C();  // Error: allocator `new` is not callable because it is annotated with `@disable`
}

Before patch: The language specification states that a static constructor is defined using the construction "static this()". Defining a constructor inside a static block does not have any effect on the constructor. The following code samples do not affect the constructor in any way:

static:
    this() {}

static
{
    this() {}
}

The compiler does not issue any warning/error on the above code samples and generates a normal constructor which is not ran before the main() function. This leads to situations in which the compiler is not able to correctly indicate the problem:

class A
{
    static
    {
        this() {}
    }

    this() {}
}

void main()
{
    new A();
}

This code will result in an error message indicating that there is a multiple definition of the constructor this() which is a misleading message.

After patch: Whenever a constructor is encountered in a static context a deprecation message is issued stating that the static keyword does not have any effect on the constructor. The solution is to declare the constructor outside the static block either as a normal constructor or a static one (static this()).

Inside a constructor scope, assigning to aggregate declaration (class/struct) members is done by considering the first assignment as initialization and subsequent assignments as modifications of the initially constructed object. For const/immutable fields the initialization is accepted in the constructor, but subsequent modifications are not. Example:

struct A
{
    int a;
    immutable int b;
    this(int a, int b)
    {
        this.a = a;
        this.b = b;

        this.a = 7; // OK, a is mutable
        this.b = 9; // Error: immutable field b initialized multiple times
    }
}

However, Bugzilla 18719 shows that this rule does not apply when inside a constructor scope there is a call to a different constructor:

struct A
{
    immmutable int a;
    this()
    {
        this(42);
        this.a = 5;  // second initialization of immutable field
    }

    this(int a)
    {
        this.a = a;
    }
}

The above code wrongfully compiled succesfully before this patch, accepting the double initialization of the immutable field a. After this patch, this.a = 5 will issue a deprecation warning stating that a is initialized multiple times.

Before this patch, the keyword this could be used as a function parameter type. This is incosistent with the meaning of this (the current instance of an aggregate declaration). In addition, accepting this as a function parameter type leads to inconsistencies when defining a struct postblit:

struct A
{
    this(this a) {}
}

In the above example this(this a) is not considered a postblit, but a constructor which has a parameter of type A named a. This is incosistent with the D optional parameter system where a function int fun(int a) is equivalent to int fun(int) if the parameter is unused.

After this patch, the compiler will issue a deprecation warning whenever it encounters this as a parameter type:

struct A
{
    this(this a) {} // Deprecation: `this` cannot be used as a parameter type.
                    //Use `typeof(this)` instead

    this(int a, this b) {} // ditto
}

Delegating constructor calls are not allowed after labels, but case labels and default labels should also count as labels.

class A
{
    this(char c) { }

    this(int i)
    {
        switch (i)
        {
            case 1:  break;
            default: break;
        }
        this('c'); // now gives an error
    }
}

This is necessary so the compiler can guarantee that each field is initialized exactly once. To get code like the above to pass the compiler, replace it with an if-then sequence.

The pow operator ^^ can now be used by CTFE.

Adds these std.math functions to those that can be used by CTFE:

round floor ceil trunc log log2 log10 pow expm1 exp2 fmin fmax copysign fma

Determines if a function's return value is placed on the stack, or is returned via registers. For more details, see isReturnOnStack.

Prior to this release any attempt to use interfaces and/or classes without the runtime would result in compile-time errors due to the lack of TypeInfo. However, as long as classes are not instantiated there is no need for TypeInfo.

Beginning with this release the compiler will no longer emit errors about missing TypeInfo when using interfaces and/or classes as long as they are not instantiated and only shared static members are utilized.

Example 1

module object

private alias extern(C) int function(char[][] args) MainFunc;
private extern (C) int _d_run_main(int argc, char** argv, MainFunc mainFunc)
{
    return mainFunc(null);  // assumes `void main()` for simplicity
}

interface I
{
    shared static int i;
}

class A : I
{
    shared static int a;
}

class B : A
{
    shared static int b;
}

void main()
{
    B.b = B.a + B.i;
}

dmd -conf= -defaultlib= main.d object.d -of=main
size main
   text    data     bss     dec     hex filename
   1867    1208      32    3107     c23 main

Non-shared static members can also be used, but will require a thread-local storage (TLS) implementation. For example, on Linux the TLS implementation is already supplied by the C runtime and C standard library, so, since dmd automatically calls gcc to link the final executable, it will automatically bring in the TLS implementation.

Example 2

module object

private alias extern(C) int function(char[][] args) MainFunc;
private extern (C) int _d_run_main(int argc, char** argv, MainFunc mainFunc)
{
    return mainFunc(null);  // assumes `void main()` for simplicity
}

interface I
{
    static int i;
}

class A : I
{
    static int a;
}

class B : A
{
    static int b;
}

void main()
{
    B.b = B.a + B.i;
}

dmd -conf= -defaultlib= main.d object.d -of=main
size main
   text    data     bss     dec     hex filename
   2123    1296      28    3447     d77 main

Some platforms may require some TLS implementation code or some specialized build procedures to link in a TLS implementation.

This will hopefully reduce friction for those using D without the runtime, porting D to new platforms, or using D from other langauges, while enabling more features and idioms of D to be used in those use cases.

Previously to call an Objective-C class method it was necessary to make explicit calls to the Objective-C runtime. The following code is an example of the old way to call a class method:

extern (C) Class objc_lookUpClass(in char* name);

extern (Objective-C)
interface Class
{
    NSObject alloc() @selector("alloc");
}

extern (Objective-C)
interface NSObject
{
    NSObject init() @selector("init");
}

void main()
{
    auto cls = objc_lookUpClass("NSObject");
    auto o = cls.alloc().init();
}

The above code can now be replaced with the following:

extern (Objective-C)
interface NSObject
{
    static NSObject alloc() @selector("alloc");
    NSObject init() @selector("init");
}

void main()
{
    auto o = NSObject.alloc().init();
}

Note the use of the static attribute in the method declaration.

Before this patch, if a postblit was declared const/immutable/shared the compiler would have accepted the declaration but there would have been no way of calling the postblit succesfully, except for const due to the implicit conversion mutable -> const. Even though calling a const posblit is possible, there is no way to modify the fields of the newly copied struct:

struct S
{
    int n
    this(this) const
    {
        ++n;   // Error: cannot modify this.n in const method
    }
}

void main()
{
    S a;
    auto a2 = a;
}

With this release, if a postblit contains const/immutable/shared in its signature, a deprecation message will be emitted.

Read-modify-write operations are not allowed for shared variables:

shared int i;
i++; // Error: read-modify-write operations are not allowed for shared variables

Use atomic.atomicOp.core instead:

import core.atomic : atomicOp;
shared int i;
atomicOp!"+="(i, 1);

Usage of a variable which is declared in another switch case now results in an error.

int i = 2;
switch (i)
{
    case 1:
    {
        int j;
    case 2:
        j++;
        j.writeln; // BUG: j is not initialized and e.g. prints -321532879
        break;
    }
    default:
        break;
}

If this behavior is wanted, it can explicitly requested by using void initialization:

int i = 2;
switch (i)
{
    case 1:
    {
        int j = void;
    case 2:
        j = 2;
        j.writeln;
        break;
    }
    default:
        break;
}