Change Log: 2.085.0

Prior to this release D interfaces were used to represent Objective-C classes. Now proper support for Objective-C classes has been added and D classes can be used instead to represent Objective-C classes. It's preferred to use D classes to represent Objective-C classes.

This release also adds support for implementing Objective-C subclasses and methods in D.

To match the behavior in Objective-C some additional changes have been made:

• static and final methods are virtual. Although final methods are virtual it's not possible to override a final method in a subclass
• static methods are overridable in subclasses

Example:

extern (Objective-C)
class NSObject
{
    static NSObject alloc() @selector("alloc");
    NSObject init() @selector("init");
    void release() @selector("release");
}

extern (Objective-C)
class Foo : NSObject
{
    override static Foo alloc() @selector("alloc");
    override Foo init() @selector("init");

    int bar(int a) @selector("bar:")
    {
        return a;
    }
}

void main()
{
    auto foo = Foo.alloc.init;
    scope (exit) foo.release();

    assert(foo.bar(3) == 3);
}

It's now possible to declare instance variables in Objective-C classes.

Instance variables in Objective-C are non-fragile. That means that the base class can change (add or remove instance variables) without the subclasses needing to recompile or relink. Thanks to this feature it's not necessary to declare instance variables when creating bindings to Objective-C classes.

Example:

extern (Objective-C)
class NSObject {}

extern (Objective-C)
class Foo : NSObject
{
    int bar;

    static Foo alloc() @selector("alloc");
    Foo init() @selector("init");
    void release() @selector("release");

    void getBar() @selector("getBar")
    {
        return bar;
    }
}

void main()
{
    auto foo = Foo.alloc.init;
    scope (exit) foo.release();
    foo.bar = 3;

    assert(foo.getBar() == 3);
}

It's now possible to implement an Objective-C method and make a super call to a method in the base class.

Example:

extern (Objective-C)
class NSObject
{
    void release() @selector("release");
}

extern (Objective-C)
class Foo : NSObject
{
    int foo() @selector("foo")
    {
        return 3;
    }
}

extern (Objective-C)
class Bar : Foo
{
    static Bar alloc() @selector("alloc");
    Bar init() @selector("init");

    override int foo() @selector("foo")
    {
        return super.foo() + 1;
    }
}

void main()
{
    auto bar = Bar.alloc.init;
    scope (exit) bar.release();

    assert(bar.foo() == 4);
}

Prior to this release, it was necessary to represent an Objective-C class as a D interface. Now support for Objective-C classes has been implemented and the class keyword should be used instead.

The reason for this deprecation is to allow extern (Objective-C) interfaces to be repurposed for representing Objective-C protocols in the future.

Deprecated:

extern (Objective-C) interface NSObject {} // deprecated

Replace with:

extern (Objective-C) class NSObject {}

With this release DMD supports generating context-aware assertion error messages when no error message has been provided by the user. For example, currently the following file:

void main()
{
    int a, b = 2;
    assert(a == b);
}

would yield this error when compiled and run:

> dmd -run main.d
core.exception.AssertError@main.d(4): Assertion failure
––––––––––
??:? _d_assertp [0x1c4eae48]
onlineapp.d:4 _Dmain [0x1c4ead85]

However, with the new experimental compiler switch -checkaction=context it yields:

> dmd -checkaction=context -run main.d
core.exception.AssertError@main.d(4): 0 != 2
––––––––––
??:? _d_assert_msg [0x4a3f9cf0]
??:? _Dmain [0x4a3f8fc4]

The new switch already supports a variety of assertion messages:

string dlang = "d2";
assert(dlang != dlang); // ERROR: "d2" == "d2"

struct S { int s; }
assert(S(0) == S(1)); // ERROR: "S(0) !is S(1)"

int a = 1, b = 2;
assert(a > b); // ERROR: 1 <= 2

Also if no error message can be generated, it will now fallback to displaying the text of the assert expression. For example, for this more complicated assert expression:

void main()
{
    int a, b = 2;
    assert(a && (a == b));
}

Compiling and running with -checkaction=context will now result in:

> dmd -checkaction=context -run main.d
core.exception.AssertError@main.d(4): assert(a && (a == b)) failed
––––––––––
??:? _d_assert_msg [0xb7e5fdfc]
??:? _Dmain [0xb7e5fd40]

This switch for context-aware assertion error messages is still experimental and feedback is welcome.

In previous versions of DMD, there was an undocumented interaction of const-cast with regular cast, ie. cast(), cast(const) and cast(immutable), where these casts would be expressed as cast(const(typeof(expr))) expr; hence if expr was of type Struct, these casts could potentially call its constructor Struct(expr), as per spec.

The dangerous part however, was if this occurred with structs that used their first field as alias this, the implicit conversion via alias this would potentially satisfy an implicit struct constructor, leaving the other fields set to init and leading to apparent data corruption from a mere cast().

In other words, cast() s to S(s) to S(s.implicitCast).

This can no longer occur, since cast(), cast(const) and cast(immutable) will no longer generate an implicit constructor call. Implicit constructor calls to S() will only occur when one explicitly uses cast(S).

With the new CLI option -verrors=context dmd will now show the offending line directly in its error messages. Consider this faulty program test.d:

void foo()
{
    a = 1;
}

Now run it with -verrors=context:

> dmd -verrors=context test.d
test.d(4): Error: undefined identifier a
    a = 1;
    ^

The compiler would sometimes generate code for struct equality tests using memcmp() across the whole struct object. This assumed that:

1. alignment holes were filled with 0, which is not always the case
2. there were no floating point NaN values, which should compare as not equal even if the bit patterns match

The spec requires that the comparison be done in a memberwise manner. This brings the implementation in line with this.

Equality Expressions

This can break existing code that relied on the former erroneous behavior. To correct such code, use one of the following:

1. define an opEquals() operator overload to achieve the desired behavior
2. use is instead of ==, as is will do a bit compare of the struct object.

This new behavior is enabled with the -preview=fieldwise compiler switch. It will eventually become the default behavior.

With this release, the DMD compiler will no longer officially support building 32-bit applications for OSX. For legacy purposes, older releases can be used.

Motivation: The latest macOS release Mojave is the last version of OSX with support for running 32-bit applications. The D development team wants to focus its efforts and build/test infrastructure on active and important platforms.

Command line switches adding or subtracting features of the D language have been normally added on an ad-hoc basis. Over time this has grown to:

• -dip25
• -dip1000
• -dip1000
• -dip1008

Moreover, in parallel -transition has been introduced and the following DMD example is only a subset of the transitional features that DMD supports at the moment:

dmd -transition=3449 -transition=10378 -transition=14246 -transition=14888 -transition=16997

While these transitions also have a name alias, it's still not clear for the user whether the transition is (a) an experimental feature or an upcoming breaking change, (b) a warning or help on an upcoming change, or (c) revert of a change for users who don't want to deal with the breaking change for now.

With this release, DMD gained a -preview command line switch which can be used to test upcoming features or potentially breaking changes. For example, with this release the list of upcoming features is:

• -preview=dip25: Implements DIP25 (Sealed references)
• -preview=dip1000: Implements DIP1000 (Scoped Pointers)
• -preview=dip1008: Implements DIP1008 (@nogc Throwables)
• -preview=markdown: Enables Markdown replacements in Ddoc
• -preview=fixAliasThis: Enables a potentially breaking fix for alias this with which DMD will first check the this scope before searching in upper scopes
• -preview=intpromote: Enables integral promotion for the unary +, - and ~ operators
• -preview=dtorfields: Enables a potentially breaking fix which enables to destruct fields of partially constructed objects

Adding new features can be disruptive to existing code bases. By initially putting them behind a -preview switch users will have ample opportunity to adapt to them at their own pace.

Therefore, for end users the new -preview interface allows a glimpse into the future. As always, feedback and bug reports for all -preview features is very welcome and encouraged, so that potential problems or breakages can be caught early.

Whenever a -preview feature gets enabled by default, it must pass on all Continuous Integrations, pass the test suite of about 50 of the most popular D packages and be without any other known major real-world issues on Bugzilla.

However, as the behavior of DMD could still deviate slightly from previous versions, sometimes a -revert switch might be introduced by the D development team which allows an easy opt-out of a new feature for users in case they run into issues. As of now, DMD offers these reverts:

• -revert=dip25: Reverts DIP25 changes
• -revert=import: Revert to single phase name lookup

Transitioning to new features (or fixing an important bug) is very often not trivial which is why an additional -transition exists. The -transition options are informational only and intended to help gauge the problems of an upcoming change or assist debugging these changes. For example, DMD currently supports these transitions:

• -transition=field: List all non-mutable fields which occupy an object instance
• -transition=checkimports: Emit deprecation messages about 10378 anomalies
• -transition=complex: Emit deprecation messages for all usages of complex or imaginary types
• -transition=tls: List all variables going into the thread local storage
• -transition=vmarkdown: List instances of Markdown replacements in Ddoc

-transition command line switches might be turned into actual deprecations if the importance of a change is considered high enough (compared to the impact on real-world code), but they are only intended as information for developers on where they would be affected by a certain transition.

As all of this information will be updated continuously with each release, all three command line switches support a help page with either h, help or ? option listing all currently available options:

> dmd -preview=help
...
> dmd -revert=help
...
> dmd -transition=help
...

IMPORTANT: All old command line switches will continue to work and won't be deprecated. However, they were removed from the documentation and new code is encouraged to use -preview or -revert where applicable.

With C++11 comes the advent of changed character type mangling. D's default behavior will be to conform to this after a one release transition period. A new switch -extern-std={c++98,c++11} is added to control the version that compatibility is set to. This switch sets __traits(getTargetInfo, "cppStd") to the value of __cplusplus that the corresponding version of the C++ standard defines.

Of particular note is the new difference between wchar and wchar_t on Windows. This will manifest itself as compile errors when interfacing wchar* with wchar_t* code when calling the Windows API. A cast will resolve the issue.

Going forward we recommend using WCHAR instead of wchar or wchar_t when interfacing to Windows API functions. (WCHAR is Microsoft Windows' 16 bit character type.)

C++ Type Equivalence

c++98 behavior:

c++11:

Name Mangling:

c++98 behavior:

c++11:

Allows access to current GC profiling information. See core.memory.GC.ProfileStats for a list of profile stats.

Added core.stdcpp.new_, which exposes interfaces for C++ global new/delete operators. This allows D programs to conveniently allocate from the C++ heap, which is useful when sharing memory between languages.

Added core.sys.linux.sched.CPU_COUNT, which returns the number of CPUs in set.

Added core.sys.linux.sched.CPU_ISSET, which tests to see if cpu is a member of set.

emplace is the counterpart to destroy, so it has been moved to also live in druntime (core/lifetime.d) where it is accessible by projects that use a shallow runtime library stack. move, moveEmplace, and forward are related low-level construction machinery which also belong in core.lifetime.

The default cleanup method for the GC is to unconditionally run a collection before runtime termination to finalize objects that are still alive and hold resources that affect system state outside the current process. This combines the worst of possible alternatives: it can cause a considerable delay and does not guarantee finalization of all objects as roots might still exist.

The cleanup behaviour can now be configured by a DRT option to the GC configuration, e.g. by passing --DRT-gcopt=cleanup:none on the command line. Three options are provided:

• collect: run a collection (the default for backward compatibility)
• none: do nothing
• finalize: all live objects are finalized unconditionally

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

extern(C) __gshared string[] rt_options = [ "gcopt=cleanup:none" ];

Precise heap scanning can now be enabled by a DRT option to the GC configuration, e.g. by passing --DRT-gcopt=gc:precise on the command line or by redefining rt_options. See the documentation for details.

The specification of core.memory.GC.realloc has changed slightly:

• GC.realloc now returns null for failure. (It used to return the original pointer but that is is not a good indication of failure as it might also be returned on success. It can lead to overwriting memory if an enlargement was requested.)
• as with GC.free, the caller has to ensure that there are no other live pointers to the memory passed to GC.realloc (This used to be required only when passing a new size 0).
• as a consequence the GC is allowed to free the memory immediately (the previous implementation did this for objects larger than 4kB when shrinking).
• block attribute bits on the existing block are only set if it is reused (the previous implementation didn't set bits if it reused a small block).

The implementation now properly verifies that pointers are actually base pointers to allocated GC memory (passing other pointers could have crashed immediately or corrupt the GC).

A GC registry has been implemented that allows to add garbage collector implementations by just linking them into the binary. See the documentation for details.

Added core.stdcpp.allocator, which exposes the C++ std::allocator<T> class. This is a required foundation for any of the allocating STL container types.

Fields that are single char/wchar or fixed-length arrays of such are now initialized to all zero bits instead of all one bits for most structs in the D runtime (core.* and rt.* modules). This simplifies initialization and removes the need to store init data when it makes the entire struct zero-initialized. Most affected structs are used for interoperability with C APIs.

dub fetch <package>@<version> is a shortcut for dub fetch <package> --version=<version>:

> dub fetch gitcompatibledubpackage@1.0.4
Fetching gitcompatibledubpackage 1.0.4...

Using attribute extraDependencyFiles a list of files can be specified causing rebuild on change.

Existing file system supplier is enabled for usage. It searches a certain directory for files with names of the form "[package name]-[version].zip".

Example dub fetch mypackage --registry=file:///etc/dub/packages/

DUB now supports a new entry in dub.json or dub.sdl to restrict the versions of DUB and of compilers supported by a package.

dub.json:

{
    "toolchainRequirements": {
        "dub": "~>1.10",
        "frontend": ">=2.068 <2.083"
    }
}

dub.sdl:

toolchainRequirements dub="~>1.10" frontend=">=2.068|<2.083"

Supported entries in toolchainRequirements are:

• dub
• frontend
• dmd
• ldc
• gdc

Each can contain a version specification, where DMD-like versions are supported in addition to SemVer versions. For compilers, instead of a version specification, the keyword no can also be used to indicate that the compiler should not be used for this package.

Example scenario:
Package that needs DUB>=1.12, and that will only build with LDC>=1.10:

dub.json:

{
    "toolchainRequirements": {
        "dub": ">=1.12",
        "dmd": "no",
        "gdc": "no",
        "ldc": ">=1.10"
    }
}

dub.sdl:

toolchainRequirements dub=">=1.12" dmd="no" gdc="no" ldc=">=1.10"