Change Log: 2.111.0

It's now deprecated to declare auto ref parameters without putting those two keywords next to each other. This way it's clear that auto ref semantics are intended, rather than ref and auto semantics separately. For the newly introduced ref local / global variables, it's an error immediately.

void t()(ref const auto int x) // Deprecation
{
    ref auto y = x; // Error
}

// Correction:
void t()(auto ref const int x)
{
    auto ref y = x;
}

If const(void)[] data contains tail const pointers, copying to void[] can subsequently violate const data:

void f(int*[] a, const int*[] b)
{
    void[] va = a;
    const void[] vb = b;
    va[] = vb[]; // fills `a` with pointers to const
    *a[0] = 0; // const data mutated
}

Copying vb data to va is no longer allowed with the -preview=fixImmutableConv switch.

This used to give a deprecation, this now gives an error:

int i;
switch (0)
{
    case 0, 1: i = 20;
    default: assert(0); // Error: switch case fallthrough - use 'goto default;' if intended
}

switch (0)
{
    default:
    case 0, 1: i = 20;
    case 2, 3: i = 30; // Error: switch case fallthrough - use 'goto case;' if intended
}

struct HasDtor
{
    ~this() {}
}

struct Pure
{
    HasDtor member;
    this(int) pure {} // Error: `this` has stricter attributes than its destructor (`pure`)
}

struct Nothrow
{
    HasDtor member;
    this(int) nothrow {} // Error: `this` has stricter attributes than its destructor (`nothrow`)
}

struct NoGC
{
    HasDtor member;
    this(int) @nogc {} // Error: `this` has stricter attributes than its destructor (`@nogc`)
}

struct Safe
{
    HasDtor member;
    this(int) @safe {} // Error: `this` has stricter attributes than its destructor (`@safe`)
}

This used to issue a deprecation, it is now an error:

void test() nothrow
in
{
    throw new Exception(null); // Error: `in` contract may throw but function is marked as `nothrow`
}
out
{
    throw new Exception(null); // Error: `out` contract may throw but function is marked as `nothrow`
}
do
{
}

The -ftime-trace switch that the LDC compiler already has, is now also available in dmd. It can be used to figure out which parts of your code take the longest to compile, so you can optimize your build times.

dmd -ftime-trace app.d

This will output app.o.time-trace.

A different output file can be selected with -ftime-trace-file=trace.json.

The output is in Google Chrome's profiler format, which can be viewed in an interactive viewer like ui.perfetto.dev.

See also this YouTube tutorial: Easily Reduce Build Times by Profiling the D Compiler

Previously you needed to manually include .c source files, it now works just like with .d files

While Import expressions are typed as string, they are also used to embed binary files. By treating them the same as hex strings, they will implicitly convert to arrays of integral types other than char.

// Formerly, a cast was required:
immutable ubyte[] iconImg = cast(immutable ubyte[]) import("icon.png");

// Now, it implicitly converts to integral arrays:
immutable ubyte[] iconImg = import("icon.png");

The following new pragma for ImportC allows to set default storage classes for function declarations:

#pragma attribute(push, [storage classes...])

The storage classes nothrow, nogc and pure are supported. Unrecognized attributes are ignored. Enabling a default storage class affects all function declarations after the pragma until it is disabled with another pragma. Declarations in includes are also affected. The following example enables @nogc and nothrow for a library:

#pragma attribute(push, nogc, nothrow)
#include <somelibrary.h>

The changed storage classes are pushed on a stack. The last change can be undone with the following pragma:

#pragma attribute(pop)

This can also disable multiple default storage classes at the same time, if they were enabled with a single #pragma attribute(push, ...) directive.

Previously, giving a name to a mixed-in mixin template instance required putting the name at the end. Now, it can also go in front of the instantiation using assignment syntax.

mixin MyMixinTemplate!(Args) myName; // old style
mixin myName = MyMixinTemplate!(Args); // new style

The switch gives fully qualified names to object files, preventing name conflicts when using the -od switch while compiling multiple modules with the same name, but inside different packages. The switch already existed in LDC, but is now in dmd as well.

Example:

dmd -c -oq -od=. app.d util/app.d misc/app.d

This will output app.obj, util.app.obj, and misc.app.obj, instead of just app.obj.

-oq also applies to other outputs, such as DDoc (-D -Dd=.) and .di header generation (-H -Hd=.).

.di interface file generation and Ddoc output will now have type qualifier attributes placed after the parameter list for methods (and constructors). This avoids confusion with the return type.

struct S
{
    const int f(); // before
    int f() const; // now
}

For example, one can now write:

struct S { int a; }

void main()
{
    S s;
    ref int r = s.a;
    r = 3;
    assert(s.a == 3);

    auto ref x = 0;
    auto ref y = x;
    static assert(!__traits(isRef, x));
    static assert( __traits(isRef, y));
}

The spec was updated (for 2.109) so that only 0 and 1 are safe values for bool. This means that reading a bool value whose underlying byte representation has other bits set is implementation-defined and should be avoided. Consequently the following are deprecated in @safe code:

• void initialization of booleans (since 2.109)
• Reading a bool field from a union (since 2.109)
• Runtime casting a dynamic array to a bool dynamic array type
• Runtime casting a bool dynamic array to a tail mutable dynamic array type
• Casting a pointer to a bool pointer type
• Casting a bool pointer to a tail mutable pointer type

The criticalRegionLock feature suffer from a serious design flaw: https://issues.dlang.org/show_bug.cgi?id=24741

It turns out it is not used, so rather than fixing the flaw, the feature was removed.

Adds the functions expect and likely/unlikely` for branch and value hints for the LDC/GDC compilers. DMD ignores these hints.

Adds trap to lowered to the target dependent trap instruction. If the target does not have a trap instruction, this intrinsic will be lowered to the call of the abort() function.

The new function is a cross between the existing std.uni.graphemeStride and std.uni.decodeGrapheme functions. The new function both supports @safe pure nothrow @nogc like graphemeStride does as long as you don't rely on autodecoding (side node: @nogc support for graphemeStride added in this release), and works with any non-array ranges just like decodeGrapheme does.

Example:

import std.uni;

// Two Union Jacks of the Great Britain in each
string s = "\U0001F1EC\U0001F1E7\U0001F1EC\U0001F1E7";
wstring ws = "\U0001F1EC\U0001F1E7\U0001F1EC\U0001F1E7";
dstring ds = "\U0001F1EC\U0001F1E7\U0001F1EC\U0001F1E7";

// String pop length in code units, not points.
assert(s.popGrapheme() == 8);
assert(ws.popGrapheme() == 4);
assert(ds.popGrapheme() == 2);

assert(s == "\U0001F1EC\U0001F1E7");
assert(ws == "\U0001F1EC\U0001F1E7");
assert(ds == "\U0001F1EC\U0001F1E7");

import std.algorithm.comparison : equal;
import std.algorithm.iteration : filter;

// Also works for non-random access ranges as long as the
// character type is 32-bit.
auto testPiece = "\r\nhello!"d.filter!(x => !x.isAlpha);
// Windows-style line ending is two code point in a single grapheme.
assert(testPiece.popGrapheme() == 2);
assert(testPiece.equal("!"d));

In case the root package directory doesn't contain a dub.selections.json file, dub now looks in parent directories too and potentially uses the first (deepest) one it finds - if and only if that JSON file contains an optional new "inheritable": true flag.

This allows using a 'central' dub.selections.json file for a repository containing multiple dub projects, making it automatically apply to all builds in that source tree if located in the repository root directory (unless a local dub.selections.json overrides it).

Such an inherited selections file is never mutated when running dub for a nested project, i.e., changes are always saved to a local dub.selections.json file. E.g., when running dub upgrade for a nested project.