Change Log: 2.107.0

In 2.104, throwing qualified types was deprecated.

It is also unsafe to catch an exception as immutable, inout or shared. This is because the exception may still be accessible through another mutable or non-shared reference. Catching an exception with those qualifiers is now deprecated.

auto e = new Exception("first");
try {
        throw e;
} catch(immutable Exception ie) { // now an error
        e.msg = "second";
        assert(ie.msg == "first"); // would fail
}

The following features/bugfixes/improvements were implemented for the experimental C++ header generator:

• Static variables used in a default argument context are now emitted using their fully qualified name.

Note: The header generator is still considered experimental, so please submit any bugs encountered to the bug tracker.

The error was introduced in 2.105.0.

dmd itself (and presumably others) do not throw Exceptions, preferring other methods for dealing with errors. There is a cost, however, in supporting Exceptions even when they are never thrown. The cost is in adding stack unwinders for things like RAII objects, and preventing numerous optimizations across try-catch boundaries.

Adding nothrow to all the code in a project turns out to be an inordinate amount of work if the program is large. Putting nothrow: at the top of the module doesn't influence the status for member functions in a class or struct, the nothrow: will have to be repeated for each class/struct.

Adding the -nothrow switch to the compiler causes the stack unwinders to not be added and enables the optimizations. This capability is already there for -betterC code, this would just enable it for regular D code.

The switch does not affect semantic analysis, just the code generation. Name mangling is not affected.

The switch is useful for determining what effect exception handling has on an executable's size and performance in non-throwing code.

CET is a technology that is useful for preventing an attacker from redirecting a program's control flow, specifically IBT prevents an attacker from causing an indirect branch to go to an unintended place.

Intel IBT expects the compiler to emit special instructions (endbr32 and endbr64) which in older processors that do not support IBT are equivalent to nop instructions, consequently a program compiled with active IBT will be compatible on any x86 processor and the protection will be opportunistically active on supported processors.

To enable Intel IBT protection in DMD you need to pass the -fIBT flag to the compiler, consequently the compiler will manage the emission of instructions for IBT by itself. Be careful when using inline assembly, the compiler will not automatically handle IBT inside an inline assembly.

To find out within a D program whether IBT has been activated or not use the traits getTargetInfo as follows:

// IBT active
static assert(__traits(getTargetInfo, "CET") == 1);  // CET == 1 if IBT is active

// IBT not active
static assert(__traits(getTargetInfo, "CET") == 0);  // CET == 0 if IBT is not active

The fix for issue 23145 broke existing code, so it's put behind -preview=DIP1000 now, just like other scope related errors.

Just like immutable data, global const data is not placed in Thread Local Storage (TLS), so initializing it in a thread-local static constructor allows you to violate const: see issue 24056 for details. Doing this will now result in a deprecation:

int x;
const int y;
immutable int z;

static this()
{
    x = 1;
    y = 2; // Deprecation: cannot modify const variable
    z = 3; // Error: cannot modify immutable variable (same as before)
}

As a corrective action, move the initialization to a shared static constructor:

const int y;

shared static this()
{
    y = 4; // OK
}

Formerly, module constructors or enum had to be used to initialize global variables with Associtive Arrays. By internally lowering to Steven Schveighoffer's newaa struct implementation, Associative Arrays can now be used directly.

immutable string[string] table = ["key": "value"];

void main()
{
    assert(table["key"] == "value");
}

When the key/value types have toHash, opEquals or ~this defined, they must be callable at compile time. An if (!__ctfe) branch can be used to make a destructor only run at run time. Future enhancements may obviate the need for this workaround.

The template _d_newarrayT now uses DBI to check what type of initialiser is required by the type of the elements in the array. Thus it replaces both _d_newarrayT and _d_newarrayiT.

_d_newarrayU is the generic implementation of both of the above hooks and just allocates the array. It hasn't been incorporated into _d_newarrayT because it is used by dup. Currently dup is still using the non-template _d_newarrayU. A future PR will update dup to use the new template.

Now the compiler performs the following lowering:

S[] s = new S[10]

// is now lowered to:
S[] s = _d_newarrayT!S(10);

This change adds the new templates to core.internal.array.construction. In addition, it implements template __arrayClearPad, __arrayAlloc, __arrayStart and __setArrayAllocLength in core.internal.array.utils. __arrayClearPad and __arrayStart were also removed from rt.lifetime. The others can't be removed yet because they receive a TypeInfo argument and are called by other hooks in rt.lifetime.

• GC.enable
• GC.disable
• GC.collect
• GC.minimize

Previously, the etc.c.odbc bindings were deprecated and forwarded the core.sys.windows versions of the bindings via public import. However, ODBC is supported on all major platforms and the machine translated MinGW bindings in core.sys.windows have version(Windows) specified which results in being unable to use those bindings on non-Windows platforms. The bindings have been returned to etc.c.odbc, undeprecated, and support for non-Windows platforms enabled.

isInputRange now has an optional 2nd template parameter that defaults to void. If not void, it only evaluates to true if the range's element type is the same type as this extra argument, modulo const. For instance, isInputRange!(int[], const(int)) is true, but isInputRange!(int[], string) is false.

Unshared is the shared equivalent of Unconst. It strips off the outer layer of shared from a type. e.g.

    static assert(Unshared!(shared int) == int);
    static assert(Unshared!(shared(int[])) == shared(int)[]);

So, Unconst strips off the outer layer of const, immutable, and inout; Unshared strips off the outer layer of shared; and Unqual strips off all qualifiers from the outer layer of a type.