Change Log: 2.104.0

When a function fails to infer a function attribute, all callers of that function also fail to infer the attribute. The resulting error message only points to the top most function with the explicit attribute:

void main() @nogc
{
    fun();
}

auto fun()
{
    funImpl();
}

auto funImpl()
{
    int[] a = [1, 2, 3];
}

app.d(4): Error: @nogc function D main cannot call non-@nogc function app.fun

This doesn't tell the underlying reason why fun wasn't inferred @nogc, and led to use of workarounds to get better information. The new error message will point to the function which failed to infer the attribute:

app.d(4): Error: @nogc function D main cannot call non-@nogc function app.fun
app.d(7):        which calls app.funImpl
app.d(14):        which wasn't inferred @nogc because of:
app.d(14):        array literal in @nogc function app.funImpl may cause a GC allocation

Note: this was already implemented for @safe since 2.101, but it has now been extended to @nogc, nothrow, and pure.

This has been deprecated since 2.075.0 because it's error prone:

void main()
{
    foreach (i; 0 .. 8);
    {
        // Because of the accidental semicolon above,
        // this block statement is executed once.
        // It's not the loop body
    }
}

It will now result in an error.

app.d(3): Error: use { } for an empty statement, not ;

In preparation for enabling -preview=in by default, using in parameters on function that have neither D nor C++ linkage is deprecated. Users can replace instances of in with either const or scope const. Refer to v2.101.0 changelog's for a full rationale.

Using in ref (or ref in) on function parameters will now yield a deprecation. Users are encouraged to remove the ref and compile with -preview=in, which will infer whether the parameter should be passed by reference or value. Users wanting a specific ABI are encouraged to use scope const ref instead. Note that this also applies to auto ref in, which is equivalent to in with -preview=in, but the latter doesn't require the function to be templated.

Previously, an immutable, const, inout or shared exception could be thrown and then caught in an unqualified catch (Exception e) clause. That breaks type safety. Throwing a qualified object is now deprecated. This helps to prevent possible mutation of an immutable object in a catch clause.

The runtime also modifies a thrown object (e.g. to contain a stack trace) which can violate const or immutable objects. Throwing qualified objects has been deprecated for this reason also.

It was already allowed to put types in UDAs, but the parser would reject basic types written directly, requiring the use of an alias.

alias Tint = int;

@Tint void f();

Also, simple literals that can appear in template instantiations without brackets (example: foo!"arg") require parentheses when used as an attribute:

@("my test") unittest
{

}

Now, arguments that can appear after a template instantiation foo! can also appear after an @ attribute.

@int void f();

@"my test" unittest
{

}

Until now, clamp used a template constraint to check if the passed types could be used. If they were not, it was very tedious to figure out why.

As the template constraint is not used for overload resolution the constrains are moved into static asserts with expressive error messages.

Rebindable can now be used to store and rebind values of any type, including immutable struct values.

To ensure const safety is preserved, the stored values cannot be accessed by reference.

The implementation used for all previously supported types (classes, interfaces and arrays) is unchanged.

rdmd now understands DMD's -shared switch, and sets the default output file name appropriately (.dll, .so, or .dylib depending on the platform), in the same way as -lib.

cSourcePaths passes the C source files in all specified directories to the compiler. All C sources found in the given directories for 'cImportPaths' are passed to the D compiler. This ensures backward compatible behaviour for projects that stored C sources aside of D source file, while porting them to D.

The second keyword 'cImportPaths' will add additional search paths for C headers. These directories are passed to the D compilers as addition include paths. The feature might need additional tweaking, because the include paths are currently joint with the D import paths. This might change in future to support independant search paths for C to be passed to the D compilers.

Previous versions of dub stored packages in the following format: $CACHE_PATH/$PACKAGE_NAME-$PACKAGE_VERSION/$PACKAGE_NAME/ Starting from this version, the format will be: $CACHE_PATH/$PACKAGE_NAME/$PACKAGE_VERSION/$PACKAGE_NAME.

Introducing a new level will help users quickly list what packages they actually have installed, and reduce visibility of packages that might update frequently. It will render various commands (e.g. du) more useful, pave the way for a package GC function, and make manual browsing easier.

More importantly, it will allow future version of dub to infer the version from the path to the package, removing the need to read (or edit) the recipe file on every dub invocation.