Change Log: 2.088.0

It's now possible to declare an alias to a function type using the alias syntax based on the assignment operator. The declaration consists of the return type, followed by parameters and ends with optional (member) function attributes. See the AliasDeclarationY rule for more details.

Example:

alias int OldStyleFunAlias(string);
alias NewStyleFunAlias = int(string);

int fun(string p){return 0;}
static assert(is(typeof(fun) == NewStyleFunAlias));

Note that an advantage compared to the old syntax is that the new allows a shortcut to function template types:

alias SetterProto(T) = void(T t);
alias GetterProto(T) = T() const;

With the -preview=markdown flag to dmd, Ddoc now supports Markdown features like headings, emphasized text, links and more. The full list of features is described in the Ddoc documentation page.

Use the -transition=vmarkdown flag together with the -preview=markdown flag to log all instances of Markdown features as they're processed in your documentation.

scope as a type constraint on class declarations has been deprecated for quite some time. However, starting with this release, the compiler will emit a deprecation warning if used.

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

Note that this does not apply to structs. Deprecation of scope as a type constraint on structs is still awaiting a decision.

Prior to this release, this and super could be used as both data or types depending on the context, but was deprecated about a year ago. Starting with this release using this or super as a type will result in a compiler error.

class C
{
    shared(this) x;    // Error: Using `this` as a type is obsolete. Use `typeof(this)` instead
}

class D : C
{
    shared(super) a;   // Error: Using `super` as a type is obsolete. Use `typeof(super)` instead
    super b;           // Error: Using `super` as a type is obsolete. Use `typeof(super)` instead
}

Use typeof(super) or typeof(this) instead.

class C
{
    shared(typeof(this)) x;
}

class D : C
{
    shared(typeof(super)) a;
    typeof(super) b;
}

With this release DMD will issue an error when some invalid integer literals like 0b or 0x are used. Example:

auto a = 0b;  // Error: `0b` isn't a valid integer literal, use `0b0` instead
auto a = 0x;  // Error: `0x` isn't a valid integer literal, use `0x0` instead

This enhancement adds two new forms of the is(), expression, which determine whether a given symbol represents a module or package.

It also adds __traits(isModule, sym) and __traits(isPackage, sym), which do the same thing.

With this release local and member templates can be instantiated with local symbols.

struct S
{
    private int _m;
    void exec(alias fun)()
    {
        fun(_m);
    }
}

unittest
{
    int localVar;

    void set(int i)
    {
        localVar = i;
    }

    auto obj = S(10);
    obj.exec!set();

    assert(localVar == 10);
}

This was a long-standing limitation that disturbed the metaprograming experience.

See issue 5710.

When specifying -mscrtlib=msvcrt100 explicitly on the command line to dmd, detection of a Visual Studio installation is skipped and the redistributable VC2010 dynamic runtime library and mingw based platform import libraries will be used unconditionally. The LLD linker (provided by the LLVM project) will be invoked instead of the Microsoft linker.

Prior to this release, float.init, double.init and real.init used a signalling nan. They now use a quiet nan, which is the same as the corresponding .nan value.

Old behaviour:

double a = double.init, b = double.nan;
writefln("%x",*cast(ulong*)&a); // 7ff4000000000000
writefln("%x",*cast(ulong*)&b); // 7ff8000000000000

New behaviour:

double a = double.init, b = double.nan;
writefln("%x",*cast(ulong*)&a); // 7ff8000000000000
writefln("%x",*cast(ulong*)&b); // 7ff8000000000000

Starting with this release any use of class allocators or deallocators will result in a compilation error.

See the deprecated features page for more information.

The -transition=import and -transition=checkimports switches no longer have an effect and are now deprecated. Symbols that are not visible in a particular scope will no longer be found by the compiler.

Prior to this release, the following code was possible:

module foo;
immutable int bar;
static this()
{
    bar = 42;
}

However, module constructors (static this) run each time a thread is spawned, and immutable data is implicitly shared, which led to immutable value being overriden every time a new thread was spawned. The simple fix for this is to use shared static this over static this, as the former is only run once per process.

Since 2.070.0, the following code has been giving deprecations:

struct Oops
{
    this (int universe = 42) {}
}

It will now error out.

With this release, templates with alias parameters can be instantiated with basic types, such as int or void function().

template Example(alias A) { alias Example = A[]; }
alias IntArray = Example!int;

template MatchType(T) { enum MatchType = "type"; }
template MatchType(alias A) { enum MatchType = "alias"; }

// alias matches, but type matches take priority.
static assert (MatchType!int == "type");

Templates with alias parameters already matched named types, lambdas, and even value literals. Templates with variadic parameters already matched basic types. This led to strange replacements for alias such as template Template(T...) if (T.length == 1). Those replacements are no longer necessary.

As a consequence, in some cases templates will match that did not used to. For instance, a template may have falsely relied on alias parameters being "something callable" vs. type parameters being "the type of something callable", such as

void fun(T...)(T callable) { ... }
void fun(alias A)() { ... }

Such overloads may now need to explicitly check whether A is callable in the second case:

void fun(alias A)() if (__traits(compiles, A())) { ... }
// shorter, but may miss cases like structs with a static opCall
void fun(alias A)() if (!isType!A) { ... }

This should substantially speed up routine float and double processing. SIMD vector operations, however, are still not support on 32 bit Linux code because of issues with 16 byte stack alignment.

This means that generated code will no longer work on older x86 processors that do not have XMM registers. If this is an issue, please file a bug report.

In FreeBSD, as in OSX, the tty part of ioctl is defined in sys/ttycom.h which is included by sys/ioctl.h. In druntime, there were OSX part of definitions in ttycom.d, but there were no FreeBSD equivalent. This change implements FreeBSD part of ttycom.d and ioccom.d, and public import core.sys.posix.sys.ttycom in ioctl.d. The OSX users and FreeBSD users can now use full ioctls related to tty by importing core.sys.posix.sys.ioctl, like including sys/ioctl.h in C language. (For example, TIOCGWINSZ ioctl was not provided in FreeBSD.) Since there are only version(OSX) and version(FreeBSD) part in ttycom.d, public import'ing core.sys.posix.sys.ttycom from ioctl.d will make no harm to other platforms.

The garbage collector now uses available CPU cores to mark the heap faster. This reduces pause times for a collection considerably.

By default, the GC uses all available logical cores of your CPU. This might affect your application if it has threads that are not suspended during the mark phase of the collection. You can configure the number of additional threads used for marking by DRT option parallel to the GC configuration, e.g. by passing --DRT-gcopt=parallel:2 on the command line. A value of 0 disables parallel marking completely.

As usual, you can also embed the configuration into the application by redefining rt_options, e.g.

extern(C) __gshared string[] rt_options = [ "gcopt=parallel:0" ];

clone(2) and unshare(2) are Linux-specific system calls. Bindings have been added to the corresponding D module, as well as the CLONE_* constants that are used as flags to these functions.

There is a new enumerated type std.ascii.ControlChar. It has values for every control character in ASCII table and has a base type of char, allowing for alternative markup of strings with control characters:

import std.ascii, std.conv;
with (ControlChar) assert(text("Phobos", us, "Deimos", us, "Tango", rs) == "Phobos\x1FDeimos\x1FTango\x1E");

On GNU/Linux usable number of processors may be restricted if a process runs in containers. In case it's better to use sched_getaffinity(2).

import std.parallelism;

writeln(totalCPUs); // 4
writeln(totalCPUs); // 1: runs on `taskset -c 0`

std.algorithm.sorting.schwartzSort now has an overloaded version that can be used to provide a SwapStrategy without also explicitly specifying the predicate to sort by.

auto s1 = a.schwartzSort!(abs, SwapStrategy.stable);

// The old syntax still works.
auto s2 = a.schwartzSort!(abs, "a < b", SwapStrategy.stable);

Phobos and Druntime are now compiled with -preview=dip1000.

This is a major milestone in the transition to DIP1000. Hence, end users can now start using -preview=dip1000 in their own code bases.

As always, any encountered issue should be reported to the issue tracker.

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.