Change Log: 2.089.0

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

• opNeg Replace with opUnary(string op)() if (op == "-")
• opCom Replace with opUnary(string op)() if (op == "~")
• opPostInc Replace with opUnary(string op)() if (op == "++")
• opPostDec Replace with opUnary(string op)() if (op == "--")
• opStar Replace with opUnary(string op)() if (op == "*")

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

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

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

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

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

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

Starting with this release, any D code that triggers a lowering to the D1 operator overloads will emit a deprecation warning.

Example of deprecation warning:

struct S
{
    int opAdd(int i) { ... }
}

void main()
{
    S s;
    int i;
    i = s + 1;  // Deprecation: `opAdd` is deprecated.  Use `opBinary` instead.
}

Example of corrective action:

struct S
{
    int opBinary(string op)(int i) if (op == "+") { ... }
}

void main()
{
    S s;
    int i;
    i = s + 1;  // OK
}

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 does 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.

Beginning with this release, whenever a constructor is encountered in a static context an error message is emitted 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()).

Before this release, deprecated on alias this was accepted by the parser but did not trigger a deprecation mesage on usage.

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:

class 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:

class A
{
    immutable 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. Starting with this release, this.a = 5 will emit an error stating that a is initialized multiple times.

Takes one argument which is a symbol. Returns a tuple(string, int, int) whose entries correspond to the filename, line number and column number where the argument was declared.

To disambiguate between overloads, pass the result of getOverloads with the desired index, to getLocation:

module m;
int foo();
int foo(int);
enum loc = __traits(getLocation, __traits(getOverloads, m, "foo")[0]);

If a struct or class with shared type implements the opUnary or opOpAssign operator then it is possible to perform "read-modify-write" operations because the operator's implementation is supposed to perform atomic operations.

The purpose of this modification is to allow the creation of wrappers (with structs or classes) to run atomic operations silently, for example:

shared struct Atomic {
    int a;

    int opUnary(string s)() if (s == "++")
    {
        import core.atomic : atomicOp;
        return atomicOp!"+="(a, 1);
    }
}

Atomic atomicvar;
atomicvar++; // Safe! Atomic struct implements opUnary

Due to a bug in dmd, members of anonymous unions inside struct declarations had their postblits/destructors called when an object of the containing struct type was copied/destroyed. With this release, the postblit/destructor is no longer called in such situations.

Fixes: https://issues.dlang.org/show_bug.cgi?id=19122

It had been deprecated in 2.061 in favor of MemoryOrder.

Existing core.atomic.cas functions discard the result, which make it impossible to implement certain operations. A new set of overloads was added which take ifThis by pointer and write the result back to the argument.

Added missing core.atomic.atomicExchange function to the atomic suite.

Namely CLOCK_MONOTONIC_RAW, CLOCK_MONOTONIC_COARSE (linux), CLOCK_MONOTONIC_PRECISE, CLOCK_MONOTONIC_FAST (FreeBSD, DragonflyBSD), and CLOCK_MONOTONIC_COARSE (CRuntime_Glibc). Those were deprecated in 2.067. They are available on their respective platform modules.

Starting with this release utilizing the callStructDtorsDuringGC runtime option will result in a deprecation message printed to stderr. The option will be removed in a future release.

They are linux extensions, not POSIX, and thus can be found in core.sys.linux.dlfcn. They had been deprecated since 2.063.

Those have been deprecated since 2.068, and are related to a language feature that is long gone.

It had been deprecated in 2.064 in favor of assertHandler.

This had been deprecated since 2.068 in favor of Fiber.call(Rethrow.[Yes|No]).

This module had been deprecated since 2.077.0. core.sys.linux.netinet.tcp should be imported instead.

They were deprecated since 2.065 in favor of rt_init C functions, which allow to initialize the runtime from C code.

Added core.stdcpp.string, which links against C++ std::basic_string

Known issues:

Currently, the GCC (libstdc++) implementation has a known issue with the modern __cxx11 ABI, because the C++ struct contains an interior pointer which is illegal in D, and incompatible with D move semantics. To use core.stdcpp.string on linux/GCC, you must use the old string ABI by supplying -D_GLIBCXX_USE_CXX11_ABI=0 to g++, and also -version=_GLIBCXX_USE_CXX98_ABI to your D compiler. Work to define D move constructors is ongoing and expected to resolve this issue when it arrives.

Added core.stdcpp.vector, which links against C++ std::vector

Previonsly, Appender.data() was used to extract a slice of the Appender's array. Now use the [] slice operator instead. The same goes for RefAppender.

std.array.Appender std.array.RefAppender

Before, it was just @system. As it turns out, all it does is return the value of an integer field, so it can have all these attributes.

Nullable's feature of implicitly converting to its contained value has been marked deprecated.

All sites where a Nullable!T is implicitly converted to T, potentially throwing an error at runtime, will now produce a deprecation warning or error with -de.

To fix this, explicitly use .get to access the contained value of the Nullable.

alias get this is the only implicit conversion in D that may throw an error. Since it is an implicit conversion, it can easily be used accidentally and lead to unexpected runtime errors. By explicitly invoking get, the developer acknowledges that the operation has a chance of error. Conversely, by not implicitly converting Nullable!T to T, the compiler gives the developer a chance to spot forgotten isNull checks.

This feature will be removed after release 2.096.

std.file.getAvailableDiskSpace receives as a parameter the path of a file or directory in the file system, and returns the available disk space on the mounted filesystem. If the given path is nonexistent, an exception is thrown.

import std.file;
ulong size = getAvailableDiskSpace(".");
assert(size > 0);

import std.file;
assertThrown(getAvailableDiskSpace("NonExistentFile"));

The JSON grammar does not allow trailing commas, however they are accepted by many JSON parsers. std.json now ignores trailing commas as well. Use JSONOptions.strictParsing to disable this behavior.

import std.json;
import std.exception : assertThrown, assertNotThrown;

// before
assertThrown(parseJSON(`{ "a" : { } , }`));

// after
assertNotThrown(parseJSON(`{ "a" : { } , }`));

The bundled libcurl is now build with DONT_USE_RECV_BEFORE_SEND_WORKAROUND. See #399 for details.

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"]

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.