Change Log: 2.094.0

Takes two arguments. The first must be a symbol or expression and the second must be a symbol, such as an alias to a member of parent. The result is member interpreted with its this context set to parent. This is the inverse of __traits(parent, member).

struct A
{
    int i;
    int foo(int j) {
        return i * j;
    }
}

alias Ai = A.i;

void main()
{
    A a;

    __traits(child, a, Ai) = 3;
    assert(a.i == 3);
    assert(__traits(child, a, A.foo)(2) == 6);
}

There were some cases where DMD wasn't able to determine the common type for array literal elements. Mismatched enums and literals containing only mutable and immutable elements should now be correctly inferred.

Every template having at least one instantiation is now printed using standard compiler diagnostics formatting for easy navigation to the point of its declaration.

All messages of this kind are sorted by descending unique instantiation count.

If the flag argument list-instances is passed (such as -vtemplates=list-instances), each location where a template was instantiated is printed along with the reason for the instantiation (implicit or explicit).

For instance, a D source file named main.d containing

void foo(int I)() { }
void goo1(int I)() { }
void goo2(int I)() { goo1!(I); }

void test()
{
    foo!(1)();
    foo!(1)();
    foo!(2)();

    goo1!(1)();

    goo2!(1)();
}

compiled with -vtemplates=list-instances will output

main.d(1): vtemplate: 3 (2 unique) instantiation(s) of template `foo(int I)()` found, they are:
main.d(7): vtemplate: explicit instance `foo!1`
main.d(8): vtemplate: explicit instance `foo!1`
main.d(9): vtemplate: explicit instance `foo!2`
main.d(2): vtemplate: 2 (1 unique) instantiation(s) of template `goo1(int I)()` found, they are:
main.d(11): vtemplate: explicit instance `goo1!1`
main.d(3): vtemplate: implicit instance `goo1!1`
main.d(3): vtemplate: 1 (1 unique) instantiation(s) of template `goo2(int I)()` found, they are:
main.d(13): vtemplate: explicit instance `goo2!1`

The C++ header generated used to write comments when it encountered non-extern(C++) declarations, e.g.

// test.d
void foo() {}

// test.h
[...]
// ignoring function test.foo because of linkage

This caused a lot of bloat in the generated header file and is now customizable via the `-HC= switch which accepts either verbose (write comments) and silent (omit comments). The default was changed to silent.

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

When writing debug code, one isn't interested statically ensuring that a function block doesn't throw, but a pleasant debugging experience as e.g. writing to the console or logfiles typically can't be nothrow. DMD already allowed to escape pure and @nogc within debug statement. With this release, exception-throwing code can be called from debug statements too:

import std.stdio;
void main() nothrow
{
    debug writeln("Your throwing log statement.");
}

Marking a function with pragma(inline, true) will now cause it to be always inlined when called, and a compile error will result if it cannot be inlined.

If the pragma(inline, true) is embedded in the function body rather than outside it, it may not always take effect. (It depends on whether the function body is analyzed before it is called or not.)

If a function marked with pragma(inline, true) cannot be inlined it will now issue a warning if and only if the -wi command line switch is given. Previously, it would issue an error.

Implicit overrides of base classes methods were deprecated in 2.075.0 (released 2017-07-19) when issue 17349 was fixed by PR 6731.

The deprecation period has now ended and the following code will always error from now:

class Base
{
    void myFunction();
    void myOtherFunction(void* ptr);
}

class Child : Base
{
    // Error: Implicitly overriding `Base.myFunction`
    void myFunction() const;
    // Error: Implicitly overriding `Base.myOtherFunction(void*)`
    void myOtherFunction(const void* ptr);
}

Previously, the compiler allowed any __vector type to be implicitly convertible with any other __vector type.

int4 x = 2;
float8 y = x;
short8 z = y / 3;

In this release, __vector types now, like static arrays, can only be implicitly converted to either qualified types of itself, or void.

const int4 a = 5;
int4 b = a;         // OK, both are int4
void16 c = a;       // OK, cast to void of same size.
float4 d = b;       // Error, cannot implicitly convert int4 to float4.

Explicit conversions between __vector types can be done, but only between vectors of the same size.

long2 a = 8;
short8 b = cast(short8)a;   // OK
short16 c = cast(short16)b; // Error, cannot cast because of different sizes.

Users of the __simd and __simd_sto intrinsics will have to either add explicit casts from void16 to the appropriate type at each use, or operate strictly with void16 vectors until a value is required to be peeked.

float4 fun1(float4 a, float4 b)
{
    a = cast(float4)__simd(XMM.ADDPD, a, b);
    a = cast(float4)__simd(XMM.ADDSS, a, b);
    return a;
}

float4 fun2(void16 a, void16 b)
{
    a = __simd(XMM.ADDPD, a, b);
    a = __simd(XMM.ADDSS, a, b);
    return cast(float4)a;
}

In earlier releases, using in on parameters would be lowered too early, leading to confusing display: error messages would show the parameter as const (or scope const if -preview=in was used), and so would header generations or stack traces. The header generation was problematic, as a header generated with -preview=in would be different from one generated without. From this release, in will now display correctly in every message. As this requires an update to the mangling, some older debuggers or tools might not be able to properly demangle functions that uses in parameters.

Ddoc's Markdown has now been enabled by default. The full list of supported Markdown features (headings, emphasized text, links, and more) is described in the Ddoc documentation page.

For the more cautious, a list of all instances of Markdown features can be logged with -transition=vmarkdown. If you encounter issues with this transition, you can temporarily disable the processing of the Markdown features with -revert=markdown and report an issue.

A huge thanks goes to David Gileadi for championing this issue!

D has supported the in, ref, and out storage classes on parameters since its inception. out and ref are commonly used, however in was usually left behind, as, while it was originally intended as an alias to const scope, it was made an alias to const when support for scope was introduced (DIP1000).

DMD v2.092.0 rectified this by adding -preview=in to mean const scope, as it was originally intended, instead of const without the switch.

However, this didn't really capture the intended meaning of in: the be applied on input parameters. Input parameters are parameters that a function intend to only examine, without modifying it, nor keeping a reference to them around. This is covered by const scope. However, some input parameters can be pretty large, or copying them can have side effects (postblit, copy constructor), hence those should be passed by reference to avoid runtime overhead. Which prompts a new issue: D doesn't support passing rvalues by references. Hence, when designing an API accepting an input parameter, a common practice was to have both an in-accepting overload, and an in ref-accepting one. While this works well for a single parameter, it also suffers from combinatorial explosion.

This release reworks the meaning of in to properly support all those use cases. in parameters will now be passed by reference when optimal, and will accept rvalue. When using the switch, in ref parameters will also trigger an error.

Note that the rules for passing by reference are as follow:

• If the type has an elaborate copy or destruction (postblit, copy constructor, destructor),

• If the type is not copy-able, it will always be passed by reference.
• Reference types (dynamic arrays, function pointers, delegates, associative arrays, classes) do not get passed by ref. This allows for covariance on delegates.
• Otherwise, if the type's size requires it, it will be passed by reference. Currently, types which are over twice the machine word size will be passed by reference, however this is controlled by the backend and can be changed based on the platform's ABI.

Previously, the compiler accepted the following code as being supported by all -mcpu= types on both OSX 32-bit and all 64-bit targets.

__vector(long[4]) x;    // AVX type
x += 1;                 // AVX2 operation

In this release, all __vector types and operations now check the current CPU being targeted for, and will issue an error if there is insufficient support.

This also allows for conditional compilation using __traits(compiles) to probe which operations are supported at compile-time.

static if (__traits(compiles, long4))
{
    // Compiled in if `-mcpu=avx` or higher
}

static if (__traits(compiles, { int4 x; x += 1; }))
{
    // Compiled in if `-mcpu=baseline` or higher
}

static if (__traits(compiles, { int4 x; x *= 1; }))
{
    // Compiled in if `-mcpu=avx` or higher
}

static if (__traits(compiles, { int8 x; x += 1; }))
{
    // Compiled in if `-mcpu=avx2` or higher
}

The following tables describe what minimum -mcpu= level is required.

Since v2.078, some array equality comparisons (e.g., if both arrays are dynamic arrays) have been wrongly using a .tupleof comparison for structs without custom opEquals, basically enforcing -preview=fieldwise for these array comparisons.

union U
{
    string s;
}

void main()
{
    static immutable from = "from", from2 = "from2";
    U[] a = [{ s : from }];
    U[1] b = [{ s : from2[0..4] }];
    assert(a[0] != b[0]);
    assert(a != b);
    assert(a != b[]); // worked before v2.078, been failing since, now working again
}

The new function core.memory.GC.allocatedInCurrentThread() returns the same as core.memory.GC.stats().allocatedInCurrentThread, but is faster, because it avoids calculating other statistics. It is used for -profile=gc and makes it faster, too.

get-path <compiler> has been added as a new action to the install script. This action allows printing information about a compiler binary. The behavior of get-path can be changed with the following additional options:

• --install install compiler if not found locally
• --dmd returns the path of a specific compiler executable (DMD-alike interface)
• --dub returns the path of the DUB executable

Examples

curl https://dlang.org/install.sh | bash -s get-path --install
/home/user/dlang/dmd-2.093.0/linux/bin64/dmd

~/dlang/install.sh get-path ldc-1.23.0 --install
/home/user/dlang/ldc-1.23.0/bin/ldc2

~/dlang/install.sh get-path --dmd ldc --install
/home/user/dlang/ldc-1.23.0/bin/ldmd2

~/dlang/install.sh get-path --dub ldc --install
/home/user/dlang/ldc-1.23.0/bin/dub

~/dlang/install.sh get-path --dub dub-1.22.0 --install
/home/user/dlang/dub-1.22.0/dub

~/dlang/install.sh get-path --dub ldc,dub-1.22.0 --install
/home/user/dlang/dub-1.22.0/dub

If a compiler installation isn't found and --install has not been passed, an error will be issued.

Binary releases for Linux, OSX, and FreeBSD are now built with LDC. This follows the switch to LDC as host compiler for Windows releases with 2.091.0.

Building DMD with LDC should provide a significant speedup of the compiler (20-30%).

This change comes with the following limitations:

• no more FreeBSD 32-bit binary releases (no 32-bit LDC host compiler)
• additional binary tools copied over from previous dmd releases are no longer included (see c0de0295e6b1f9a802bb04a97cca9f06c5b0dccd (optlink still included)) They are still available via https://digitalmars.com/ or from older dmd releases.

On windows dmd the x86_omf architecture can now be used as platform specification using --arch=x86_omf. This is currently equivalent to the previously existing --arch=x86 argument.

When calling a command with a package name and no version specification, the latest version is usually assumed. While this behavior makes sense for dub fetch or dub run, it can come as a surprise when cleaning up local packages through dub remove, and so previous version would simply error out when more than one version was available. From this version, dub remove -n $PKGNAME will just remove all cached versions of the package named $PKGNAME, without asking you to use $PKGNAME@*.

Prior to this change, accidentally running dub upgrade in a folder where no dub.json / dub.sdl was present would leave you with a dub.selections.json and, in some instances, an empty .dub folder. This has been fixed and running dub upgrade where one shouldn't will now only generate a friendly error message.

Git repositories can be directly used by dub as dependencies.

dub.json:

{
    "name": "git-dependency",
    "dependencies": {
        "gitcompatibledubpackage": {
            "repository": "git+https://github.com/dlang-community/gitcompatibledubpackage.git",
            "version": "ccb31bf6a655437176ec02e04c2305a8c7c90d67"
        }
    }
}

dub commands had some disparity in their version handling. Most commands accepting a package name (e.g. dub fetch or dub run) supported either package[@version-spec], or supported only package and accepted an option --version=<version-spec>. The latter form has now been deprecated and all commands now accept package[@<version-spec>]. Note that the absence of @<package-spec> still means "latest version" (except for remove).