Change Log: 2.087.0

With this release DMD will issue an error when a symbol that is privately imported in the scope of an aggregate declaration is used as a member of the aggregate outside of the module where the aggregate is defined. Example:

// a.d
class Foobar
{
    int a;
    this(int a)
    {
        this.a = a;
    }
    static int smeth()
    {
        return 1;
    }
}
void fun() {}

// b.d
struct AST
{
    import a;
}

// c.d
void main()
{
    import b;
    AST.Foobar t;        // triggered a deprecation, but will now trigger an error
    AST.Foobar.smeth();  // error
    AST.fun();           // error
}

Before this patch, if a struct had an aliased this member that defined an opEquals method, the aliased this opEquals would have been preferred instead of the struct one:

struct A
{
    int a, b;
    bool opEquals(ref A rhs) const
    {
        return a == rhs.a && b == rhs.b;
    }
}

struct B
{
    int n;
    A a;
    alias a this;
}

void main()
{
    B a, b;
    assert(a == b);    // rewritten to a.a.opEquals(b.a)
}

Although the compiler generates an opEquals for struct B that does member-wise equality comparison (==), the aliased this one is wrongfully preferred.

This patch corrects this issue by always choosing the defined opEquals (even if it is generated by the compiler) instead of the alias this one. If the behavior prior to this patch is desired, an explicit opEquals needs to be provided.

References: [1] https://issues.dlang.org/show_bug.cgi?id=16657 [2] https://github.com/dlang/dmd/pull/9289 [3] https://github.com/dlang/dlang.org/pull/2593

With this release, the D language compiler implements the full functionality of the copy constructor described extensively in this DIP [1].

Copy constructors are used to initialize a struct instance from another struct of the same type.

A constructor declaration is a copy constructor declaration if and only if it is a constructor declaration that takes only one non-default parameter by reference that is of the same type as typeof(this), followed by any number of default parameters:

struct A
{
    this(ref return scope A rhs) {}                        // copy constructor
    this(ref return scope const A rhs, int b = 7) {}       // copy constructor with default parameter
}

The copy constructor is type checked as a normal constructor.

If a copy constructor is defined, implicit calls to it will be inserted in the following situations:

1. When a variable is explicitly initialized:

struct A
{
    this(ref return scope A rhs) {}
}

void main()
{
    A a;
    A b = a; // copy constructor gets called
}

HexString literals are obsolete.

Prior to this release, usage of hex string literals would emit a deprecation warning. Starting with this release they will emit an error.

Use std.conv.hexString instead.

With this release DMD will issue an error when a symbol that is privately and selectively imported in module A is accessed in module B that imports module A non-selectively. Example:

// a.d
import fun : foo;

// b.d
import a;

void main()
{
    foo();     // deprecation up until now; error from now on
}

To make the above code compile, the import in a.d needs to be made public.

Prior to this release, there was no way to declare a function that would return a reference by using an anonymous function.
(It was possible to return a pointer but it's not worth mentioning.)

Here this function returns by value:

alias fn = () => a += 2;

In order to return by reference, we needed to define a named function to assign from:

ref int func()        // a static or non-nested function to mimic a `function` literal
{                     // or a non-static nested function to mimic a `delegate` literal
    return a += 2;
}
alias fn = func;

Now it's possible to use the ref keyword to indicate a return by reference:

function ref () { return x; }    // `=>` shorthand is there too
delegate ref () { return x; }
ref () { return x; }

For example:

int x = 1;
alias add2 = ref () => x += 2;
add2() += 7;    // add2 as a lvalue
assert(x == 10);

It enables the garbage collector for the compiler, trading compile times for (in some cases, significantly) less memory requirements.

E.g., compiling DMD's test tool d_do_test (dmd -c [-lowmem] test/tools/d_do_test.d) requires about 75% less memory (~1,630 MB -> 410) at the cost of a runtime increase by ~30% (~4.8 secs -> 6.3).

The following traits can now access non-public members:

• getMember
• getOverloads

This fixes a long-standing issue in D where the allMembers trait would correctly return non-public members but those non-public members would be inaccessible to other traits.

See BugZilla issue 15371

This module provides a cross-platform interface for lightweight signaling of other threads. It can be used to start execution of multiple waiting threads simultaneously.

Previously the algorithm was allocating the amount of memory which was equal to the size of the biggest range, that is Ο(max(s.length, t.length)). This is now fixed to be Ο(min(s.length, t.length)). For more details see std.algorithm.comparison.levenshteinDistance.

std.experimental.all allowed the convenient use of all Phobos modules with one import (import std.experimental.all;). With this release, this convenience module has been stabilized and moved to std. From now on, the convenience module can be accessed with import std;:

import std;
void main()
{
    5f.iota.map!exp2.sum; // 31
}

Scripts and experimental code often use long and frequently changing lists of imports from the standard library.

With this release it is possible to use import std; for importing the entire standard library at once. This can be used for fast prototyping or REPLs:

import std;
void main()
{
    6.iota
      .filter!(a => a % 2) // 1 3 5
      .map!(a => a * 2) // 2 6 10
      .tee!writeln // peek into the processed stream
      .substitute(6, -6) // 2 -6 10
      .mean // (2 - 6 + 10) / 3
      .reverseArgs!writefln("Sum: %.2f"); // 2
}

As before, symbol conflicts will only arise if a symbol with collisions is used. In this case, static imports or renamed imports can be used to uniquely select a specific symbol.

The baseline cost for import std; is less than half a second (varying from system to system) and work is in progress to reduce this overhead even further.

The bundled LLD Linker on Windows binaries has been upgraded to 8.0.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: ```json "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.