Change Log: 2.091.0

The underlying delegate of the lazy parameter may be extracted using the & operator:

void test(lazy int dg)
{
    int delegate() dg_ = &dg;
    assert(dg_() == 7);
    assert(dg == dg_());
}

void main()
{
    int a = 7;
    test(a);
}

Previously this caused a compile error.

A new function exposing information about the state of the GC was added. It returns true if the current thread is executing destructors (finalizers) of objects allocated on the GC heap that are either:

• no longer being referenced
• to whose finalizers an explicit call to GC.runFinalizers was made (usually as part of shared library unloading).

Destructors of objects allocated on the GC heap presently have several limitations or oddities:

• As destructors of all unreachable objects are ran in indeterministic order, there's no guarantee that object members are alive during the object's finalization
• Allocation during finalization is disallowed
• In contrast to stack allocated objects, partially constructed objects (object whose constructor threw an exception) may be finalized

core.memory.GC.inFinalizer can be used to efficiently guard against programming errors such as the above, or to detect whether certain objects were left to be destroyed by the GC.

A new module (core.internal.execinfo) has been added for platform dependent execinfo detection. On every POSIX system which provides an execinfo implementation as part of its C runtime the appropriate implementation- dependent execinfo module will be imported automatically.

Besides that, there is an opportunity for using external execinfo implementations built as separated libraries and linking DRuntime with them.

IMPORTANT: On platforms with C runtime not providing execinfo functionality one should decide whether an external lib (e.g. libexecinfo) will be used, or not. If not, DRuntime should be built normally without any additional version ID, but with external lib exactly one of the following version IDs should be chosen at compile time. That means, the selected external format cannot be changed later without rebuilding DRuntime.

It could be really important to keep this in mind when someone is packaging DRuntime for such OSs (e.g. ones using musl libc) and provide packages with and without execinfo support (with the specific external library as dependency) or in the case of source based packages, make this build option selectable (e.g. portage).

These formats above cover most of the "classic" backtrace outputs but as a new important format emerges, it can be easily added.

The intrinsic core.math.toPrec forces rounding of it floating point argument to the precision of float, double, or real.

Some floating point algorithms, such as Kahan-Babuska-Neumaier Summation, require rounding to specific precisions. Rounding to precision after every operation, however, loses overall precision in the general case and is a runtime performance problem.

Adding these functions guarantee the rounding at required points in the code, and document where in the algorithm the requirement exists.

Switched the default for unittests to only run the tests by default. Use --DRT-testmode=run-main for the original behavior (run unittests then main).

The feature to control unit testing was added in 2.078.0, and the switch above will work for all versions since then.

The overload accepting a callable was deprecated since 2.079 and has now been removed. Use the overload accepting an output range instead.

This specialisation of reverseArgs accepting exactly two arguments was deprecated since 2.079 and has now been removed. Use reverseArgs instead.

The overload accepting a callable was deprecated since 2.079 and has now been removed. Use the overload accepting an output range instead.

All symbols contained in Phobos can now be used with import std

This getter will try to return underlying json type as T if possible. It is convenient for automatic integer conversion like this:

import std.json;
string s = `{ "a": 123 }`;
auto json = parseJSON(s);

// This will throw with json["a"].floating
assert(json["a"].get!double == 123.0);

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.