Change Log: 2.081.0

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()).

Prior to this release, this and super could be used as both data or types depending on the context. Starting with this release using this or super as a type will result in a compiler error.

class C
{
    shared(this) x;    // Deprecation: Using `this` as a type is deprecated. Use `typeof(this)` instead
}

class D : C
{
    shared(super) a;   // Deprecation: Using `super` as a type is deprecated. Use `typeof(super)` instead
    super b;           // Deprecation: Using `super` as a type is deprecated. Use `typeof(super)` instead
}

Use typeof(super) or typeof(this) instead.

class C
{
    shared(typeof(this)) x;
}

class D : C
{
    shared(typeof(super)) a;
    typeof(super) b;
}

Expression-based contract syntax has been added: Contracts that consist of a single assertion can now be written more succinctly and multiple in or out contracts can be specified for the same function.

Example:

class C {
    private int x;
    invariant(x >= 0);
    // ...
}

int fun(ref int a, int b)
    in(a > 0)
    in(b >= 0, "b cannot be negative")
    out(r; r > 0, "return must be positive")
    out(; a != 0)
{
    // ...
}

Many improvements have been made to the extern(C++) experience in this release cycle.

Mangling improvements include:

• Constructor/destructor mangling matches C++
• Compatible D style operators now mangle as C++ operators
• nullptr_t mangles correctly
• Various mangling bugs have been fixed

extern(C++) APIs that use nullptr_t can use typeof(null) on the D side:

alias nullptr_t = typeof(null);
extern (C++) void fun(nullptr_t);

extern (C++) mangling of operators is working for all operators that are semantically equivalent. This list includes all instantiations of opUnary, opBinary, opAssign, opOpAssign, opCast, opEquals, opIndex, opCall. Two notable exceptions are opCmp, and C++ operator !, which don't have compatible implementations.

Mangling of extern (C++) class constructors and destructor are working.

This release also includes ABI fixes where destructors are now correctly added to the virtual table, and constructor/destructor calling semantics now match C++. With this, mixed-language class hierarchies are working, with construction/destruction being supported in either language.

__traits(getOverloads) has been extended to return template overloads when passed an optional parameter with a true value.

struct S
{
    static int foo()() { return 0; }
    static int foo()(int n) { return 1; }
    static int foo(string s) { return 2; }
    enum foo(int[] arr) = arr.length;
}

alias AliasSeq(T...) = T;

alias allFoos = AliasSeq!(__traits(getOverloads, S, "foo", true));

static assert(allFoos.length == 4);

static assert(allFoos[0]("") == 2);
static assert(allFoos[1]() == 0);
static assert(allFoos[2](1) == 1);
alias foo3 = allFoos[3];
static assert(foo3!([]) == 0);

It is now possible to detect the language ABI specified for a struct, class, or interface.

class MyClass {}
extern (C++) struct MyCPPStruct {}
extern (C++) interface MyCPPInterface {}
extern (Objective-C) interface MyObjcInterface {}
static assert(__traits(getLinkage, MyClass) == "D");
static assert(__traits(getLinkage, MyCPPStruct) == "C++");
static assert(__traits(getLinkage, MyCPPInterface) == "C++");
static assert(__traits(getLinkage, MyObjcInterface) == "Objective-C");

See the Deprecated Features for more information.

Implicit catch statements were deprecated in 2.072. Starting with this release, implicit catch statements will cause the compiler to emit an error.

import std.stdio;

void main()
{
    int[] arr = new int[](10);
    // This will throw a RangeError
    try { arr[42]++; }
    catch  // Error: `catch` statement without an exception specification is deprecated;
           // use `catch(Throwable)` for old behavior
    {
        writeln("An error was caught and ignored");
    }
}

See the Deprecated Features for more information.

Implicit comparison of different enums was deprecated in 2.075. Starting with this release, implicit comparison of different enums will cause the compiler to emit an error.

enum Status
{
    good,
    bad
}
enum OtherStatus
{
    ok,
    no
}
static assert(Status.good == OtherStatus.ok); // Error: Comparison between different enumeration types `Status` and `OtherStatus`;
                                              // If this behavior is intended consider using `std.conv.asOriginalType`

See the Deprecated Features for more information.

Implicit string concatenation was deprecated in 2.072. Starting with this release, implicit string concatenation will cause the compiler to emit an error.

void main()
{
    string s = "Hello" ", World!";  // Error: Implicit string concatenation is deprecated, use "" ~ "" instead
}

IRETQ is the 64-bit version of the already supported IRET instruction. With its inclusion, it is now possible to write 64-bit interrupt service routines in pure D.

void isr()
{
    asm
    {
        naked;
        // ...
        iretq;
    }
}

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.

Specifying redundant storage classes was deprecated long ago and was originally scheduled to emit a compiler error beginning with the 2.068 release. That promise has been fulfilled with this release.

@safe void f() @safe {}   // Error: redundant attribute `@safe`

When an exception is throw and not caught, a stacktrace is printed. On Linux, FreeBSD and DragonFlyBSD this stacktrace includes the filenames and line numbers, if the application was built with debug info enabled. This feature has now been added to macOS.

This requires support from the compiler since debug info is stripped by the linker on macOS.

Example:

void bar()
{
    throw new Exception("bar");
}

void foo()
{
    bar();
}

void main()
{
    foo();
}

Compiling the above code, with debug info enabled, by running: dmd -g main.d. When running the application it will produce an output similar to:

[email protected](3): bar
main.d:3 void main.bar() [0x71afdfb]
main.d:8 void main.foo() [0x71afe0c]
main.d:13 _Dmain [0x71afd78]

object.destroy() was crashing when called with an extern(C++) class. It now correctly destructs and resets the object to init.

Declarations that were missing from mach-o/getsect.h has been added to core.sys.darwin.mach.getsect.

Use the core.stdc package instead.

DMD

> dmd -O -inline -release ./joiner.d && ./joiner
before.joiner   = 57 secs, 834 ms, 289 μs, and 3 hnsecs
new.joiner      = 44 secs, 936 ms, 706 μs, and 5 hnsecs

LDC

> ldmd -O3 -release -inline joiner.d && ./joiner
before.joiner   = 5 secs, 180 ms, 193 μs, and 7 hnsecs
new.joiner      = 3 secs, 168 ms, 560 μs, and 6 hnsecs

The benchmark code can be found here.

Previously, without being stated in the documentation, std.algorithm.remove used to accept any values as offset. This behavior was very error-prone:

import std.algorithm, std.stdio;
[0, 1, 2, 3, 4].remove(1, 3).writeln; // 0, 2, 4  -- correct
[0, 1, 2, 3, 4].remove([1, 3]).writeln; // 0, 3, 4  -- incorrect

With this release, using arrays as individual elements is no longer valid. std.typecons.tuple can be used to explicitly indicate that a range from start to stop (non-enclosing) should be removed:

import std.algorithm, std.stdio, std.typecons;
[0, 1, 2, 3, 4].remove(tuple(1, 3)).writeln; // 0, 3, 4

However, only 2-tuples are allowed to avoid this un-intuitive scenario:

import std.algorithm, std.stdio, std.typecons;
[0, 1, 2, 3, 4].remove(tuple(1, 3, 4)).writeln; // 0, 4?

The semantics of std.math.fmin and std.math.fmax have been streamlined with the C functions: if one of the arguments is a NaN, return the other. This involves an additional std.math.isNaN check. Use std.algorithm.comparison.min and std.algorithm.comparison.max for the previous semantics performing a single comparison.

import std.math;
assert(fmin(real.nan, 2.0L) == 2.0L);
assert(fmin(2.0L, real.nan) == 2.0L); // previously: NaN
assert(isNaN(fmin(real.nan, real.nan)));

import std.algorithm.comparison;
assert(min(real.nan, 2.0L) == 2.0L);
assert(isNaN(min(2.0L, real.nan)));
assert(isNaN(min(real.nan, real.nan)));

With this release DUB allows defining additional paths that contain packages in subfolders with the pattern "(name)-(version)/(name)/" by defining a "customCachePaths" field in /etc/dub/settings.json or ~/.dub/settings.json.

"customCachePaths" can be used to provide prebuilt DUB libraries (e.g. for distribution package maintainers).