Change Log: 2.100.0

Starting with this release, alias this may not be used for the partial assignment of a left-hand side operand. Any such assignment will result in a compiler error.

If a struct has a single member which is aliased this directly or aliased to a ref getter function that returns the mentioned member, then alias this may be used since the object will be fully initialised.

struct Allowed
{
    int onemember;
    alias onemember this;
}

struct Rejected
{
    int aliased;
    long other;
    alias aliased this;
}

void fun(Allowed a, Rejected r)
{
    a = 0; // OK, struct has only one member.
    r = 0; // Error, cannot use `alias this` to partially initialize variable `r` of type `Rejected`. Use `r.aliased`
}

Starting with this release, any use of the deprecated D1 overload operators will result in a compiler error.

The corrective action is to replace all operators with their D2 equivalent.

The following D1 operator overloads have been removed in favor of opUnary:

• opNeg must be replaced with opUnary(string op)() if (op == "-")
• opCom must be replaced with opUnary(string op)() if (op == "~")
• opPostIncmust be replaced with opUnary(string op)() if (op == "++")
• opPostDecmust be replaced with opUnary(string op)() if (op == "--")
• opStarmust be replaced with opUnary(string op)() if (op == "*")

The following D1 operator overloads have been removed in favor of opBinary:

• opAdd must be replaced with opBinary(string op)(...) if (op == "+")
• opSub must be replaced with opBinary(string op)(...) if (op == "-")
• opMul must be replaced with opBinary(string op)(...) if (op == "*")
• opDiv must be replaced with opBinary(string op)(...) if (op == "/")
• opMod must be replaced with opBinary(string op)(...) if (op == "%")
• opAnd must be replaced with opBinary(string op)(...) if (op == "&")
• opXor must be replaced with opBinary(string op)(...) if (op == "^")
• opOr must be replaced with opBinary(string op)(...) if (op == "|")
• opShl must be replaced with opBinary(string op)(...) if (op == "<<")
• opShr must be replaced with opBinary(string op)(...) if (op == ">>")
• opUShr must be replaced with opBinary(string op)(...) if (op == ">>>")
• opCat must be replaced with opBinary(string op)(...) if (op == "~")
• opIn must be replaced with opBinary(string op)(...) if (op == "in")

The following D1 operator overloads have been removed in favor of opBinaryRight:

• opAdd_r must be replaced with opBinaryRight(string op)(...) if (op == "+")
• opSub_r must be replaced with opBinaryRight(string op)(...) if (op == "-")
• opMul_r must be replaced with opBinaryRight(string op)(...) if (op == "*")
• opDiv_r must be replaced with opBinaryRight(string op)(...) if (op == "/")
• opMod_r must be replaced with opBinaryRight(string op)(...) if (op == "%")
• opAnd_r must be replaced with opBinaryRight(string op)(...) if (op == "&")
• opXor_r must be replaced with opBinaryRight(string op)(...) if (op == "^")
• opOr_r must be replaced with opBinaryRight(string op)(...) if (op == "|")
• opShl_r must be replaced with opBinaryRight(string op)(...) if (op == "<<")
• opShr_r must be replaced with opBinaryRight(string op)(...) if (op == ">>")
• opUShr_r must be replaced with opBinaryRight(string op)(...) if (op == ">>>")
• opCat_r must be replaced with opBinaryRight(string op)(...) if (op == "~")
• opIn_r must be replaced with opBinaryRight(string op)(...) if (op == "in")

Note: The opBinaryRight overload operator takes precedence over any opBinary operators.

The following D1 operator overloads have been removed in favor of opOpAssign:

• opAddAssign must be replaced with opOpAssign(string op)(...) if (op == "+")
• opSubAssign must be replaced with opOpAssign(string op)(...) if (op == "-")
• opMulAssign must be replaced with opOpAssign(string op)(...) if (op == "*")
• opDivAssign must be replaced with opOpAssign(string op)(...) if (op == "/")
• opModAssign must be replaced with opOpAssign(string op)(...) if (op == "%")
• opAndAssign must be replaced with opOpAssign(string op)(...) if (op == "&")
• opOrAssign must be replaced with opOpAssign(string op)(...) if (op == "|")
• opXorAssign must be replaced with opOpAssign(string op)(...) if (op == "^")
• opShlAssign must be replaced with opOpAssign(string op)(...) if (op == "<<")
• opShrAssign must be replaced with opOpAssign(string op)(...) if (op == ">>")
• opUShrAssign must be replaced with opOpAssign(string op)(...) if (op == ">>>")
• opCatAssign must be replaced with opOpAssign(string op)(...) if (op == "~")

The following D1 operator overloads have been removed in favor of alias this:

• opDot must be replaced with alias this

scope as a type constraint on class declarations was meant to force users of a class to scope allocate it, which resulted in the class being placed on the stack rather than GC-allocated. While it has been scheduled for deprecation for quite some time, the compiler will emit a deprecation warning on usage starting from this release.

scope as a type constraint on struct or enum declarations has never had any effect, and has been deprecated as well.

scope class C { }  // Deprecation: `scope` as a type constraint is deprecated. Use `scope` at the usage site.
scope struct S { } // Ditto
scope enum E { }   // Ditto

Using scope to stack-allocate class is still suported, only the type constraint is deprecated.

class C { }

void main () @nogc
{
    scope c = new C;
}

See the Deprecated Features for more information.

Starting with this release, using asm blocks will assume to be @system, @nogc, impure and might throw, unless explicitly annotated.

See the Deprecated Features for more information.

Starting with this release, using the delete keyword will result in a compiler error.

As a replacement, users are encouraged to use destroy if feasible, or core.memory.__delete as a last resort.

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

• The implicitly generated context pointer for nested aggregates is now emitted as outer instead of this
• Explicit mangling via pragma(mangle, "...") is partially supported for functions / variables. The mangling is used as the identifier of extern(C) declarations because C doesn't mangle declaration names. extern(C++) declarations are ignored because there's no portable alternative for C++.
• Emits destructors not easily accessible from C++ (e.g. extern(D)) as private members, preventing the creation of instances that would not be destroyed on the C++ side.
• No longer generates extern(C) functions in aggregates that are emitted with D mangling.

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

Starting with this release, using scope as a type constraint on interface declarations will result in a compiler error.

scope interface I { }  // Error: `scope` as a type constraint is obsolete.  Use `scope` at the usage site.

The compiler would formerly add the return attribute to inout functions, under the assumption that every inout function would return its argument. However, it could also return a member of the inout argument, which would still be inout because const and immutable are transitive, while return semantics are not transitive.

@safe:

struct Node
{
    Node* next;
    int x;

    // This escapes a pointer to this struct
    // This used to be allowed because of `inout`
    @safe inout(int)* getScopePointer() inout
    {
        return &this.x;
    }

    // But what if you do not return a pointer to this struct?
    // `inout` applies because it's transitive, but `return ref` does not
    // The compiler could needlessly treat the returned pointer as a scope pointer
    @safe inout(int)* getNonScopePointer() inout
    {
        return &this.next.x;
    }

    // Corrective action for the first case:
    // if you want `inout` + `return ref`, annotate it with both
    @safe inout(int)* getScopePointer() inout return
    {
        return &this.x;
    }
}

Sometimes it is useful to compile code only when invariants are enabled. This feature provides the reserved version identifier D_Invariants which evaluates to true or false when invariants are compiled in or not respectively.

bool hit;

class Foo
{
    this() {}
    invariant { hit = true; }
}

void main()
{
    cast(void) new Foo();

    version(D_Invariants) assert(hit); // runs if invariants are compiled in
}

@mustuse is a new attribute that can be applied to a struct or union type to make ignoring an expression of that type into a compile-time error. It can be used to implement alternative error-handling mechanisms for code that cannot use exceptions, including @nogc and BetterC code.

For more information, see DIP 1038.

The .tupleof property may now be used with instances of static arrays, yielding an lvalue sequence of each element in the array.

Note that this is only for static array instances. It remains an error when used on a type, to avoid breaking older code lacking suitable checks. As a workaround, use typeof((T[N]).init.tupleof).

void foo(int, int, int) { /* ... */ }

int[3] ia = [1, 2, 3];
foo(ia.tupleof); // same as `foo(1, 2, 3);`

float[3] fa;
//fa = ia; // error
fa.tupleof = ia.tupleof;
assert(fa == [1F, 2F, 3F]);

Prior to this release, using this or super as a type resulted in a compiler error suggesting to use typeof(this) or typeof(super) instead. This has now been completely removed from the language, and the parser won't recognize this wrong code anymore.

Forgetting a break; statement in a switch case has been turned from a deprecation into an error in DMD 2.099.0. However, the compiler would not issue an error when using multiple values in a single case statement:

void main()
{
    int i = 0;
    switch (10)
    {
        case 10, 11:
            i = 4;
            // accidental falltrough allowed
        default:
            i = 8;
    }
    assert(i == 4); // fails
}

This bug has been fixed, but to avoid breaking code, this specific case now issues a deprecation warning. Starting from DMD 2.110, it will produce an error just like other cases of switch case fallthrough.

It is used to pass the fields of a struct as arguments to a function. For example, it can be used in a range pipeline to give names to the elements of a std.typecons.Tuple:

import std.stdio;
import std.range;
import std.algorithm;
import std.functional;

void printWithLineNumbers(File f)
{
    f.byLine
        .enumerate
        .each!(bind!((num, line) {
            writefln("%8d %s", num, line);
        }));
}

See the standard library documentation for more information.

Nullable now offers an alternative 0 or 1 element range interface.

import std.stdio;
import std.algorithm;
import std.typecons;

void printValues(Nullable!int[] values)
{
    values.joiner.each!writeln();
}

The bundled zlib has been updated to version 1.2.12.

rdmd now uses the RDMD_DMD environment variable, if it is present in the environment, to choose the D compiler to use. As with the --compiler option, the variable's value must specify the name or path of a compiler with a DMD-like command line syntax, such as gdmd or ldmd2. The variable overrides the default (which is decided at the time rdmd was built), but can still be overridden by the --compiler option.

Dub will no longer build dynamicLibrary targetType's as staticLibrary.

Except for x86_omf. This has been disabled due to numerous issues that will lead this to not doing what is expected of it.

No compiler or linker flags have been added at this time, you will need to specify the relevant flag to get the compiler to link dynamically against Phobos.

The $DUB_BUILD_PATH variable is now defined inside the postBuildCommands section. It contains the absolute path in which the package was built, and can be used to copy by-products of the build process to their intended locations.

For example, if an executable exports symbols, you will want to make the resulting import library and symbols export file available somewhere. That can be done with a dub.json section like this:

    "postBuildCommands-windows": [
        "copy /y $DUB_BUILD_PATH\\$DUB_TARGET_NAME.lib $PACKAGE_DIR\\lib"
        "copy /y $DUB_BUILD_PATH\\$DUB_TARGET_NAME.exp $PACKAGE_DIR\\lib"
    ],

Now users can use the documented predefined variables inside custom command directives without the need for a wrapper shell script.

Before this would have failed:

"preBuildCommands": ["$DC -run foo.d"]

unless DC was defined as environment variable outside DUB.

It was before possible to run a script that used the $DC environment variable or on POSIX escape the $ with $$DC to make the shell substitute the variable. These workarounds are no longer needed now.

API change: none of the different command directives are no longer substituted with the process environment variables. You now access the raw commands as provided by the user in the recipe. dub describe has been adjusted and now also processes the predefined environment variables as well as the process environment variables.

For Linux distributions that put the dub installation in /usr, there is now a special case that DUB will load from /etc/dub/settings.json (absolute path) if the installation is inside /usr.

Previously settings would have attempted to be loaded from /usr/etc/dub/settings.json if installed in /usr/bin/dub. This is still loaded if it exists, but if not /etc/dub/settings.json will be loaded.

Each (sub)package now supports a source file that will be included in any executable or dynamic library that depends either directly or indirectly on it.

This can be used to register and unregister elements of a package within the dependant package without requiring the dependant to acknowledge that the registration mechanism needs to take place.

A comparable existing feature to this is the usage of sourceLibrary target type. A sourceLibrary targetType defers compilation of source code until it is dependent upon by a static library, dynamic library or executable (sub)package. Unlike sourceLibrary the injection of source code using this feature will inject it into every dynamic library and executable that depends on it, regardless of how deep it is in the dependency graph.