Change Log: 2.103.0

Having multiple definitions of functions within a module had been turned into an error in DMD 2.095.0.

However, the compiler would not issue an error when two implementations differed by an explicit and inferred @system attribute, although they have the same mangling.

void foo() {}
void foo() @system {} // no error

This bug has been fixed, and DMD will now issue a deprecation if there are such conflicting @system function implementations. Starting from DMD 2.112, it will produce a multiple definition error just like other kinds of conflicting functions within a module.

Up until this release, __traits(getAttributes) could be called both on individual functions and on overload sets. However, in the latter case, the compiler simply collected the user defined attributes for the first lexically defined function. This behavior is error prone. Consider:

module test;

@("gigi")
void fun() {}
@("mimi")
void fun(int) {}

void main()
{
    static foreach(attr; __traits(getAttributes, fun))
        pragma(msg, attr);

The above code will print "gigi" although there is no indication on what overload is actually queried. The first one is always picked.

Starting with this release, this sort of usage of __traits(getAttributes) is deprecated. If a specific overload needs to be handled, __traits(getOverloads) may be used in conjunction with __traits(getAttributes) for proper behavior:

module test;

@("gigi")
void fun() {}
@("mimi")
void fun(int) {}

void main()
{
    static foreach (t; __traits(getOverloads, test, "fun"))
        static foreach(attr; __traits(getAttributes, t))
            pragma(msg, attr);

The above code prints:

gigi
mimi

The last clause of a for statement should not produce a value without also having some meaningful side-effect. This is now detected with a deprecation message. The following for statements each trigger the deprecation:

// evaluating `j` has no side-effects
int j;
for (;; j) {...}

// unnecessary dereference
for (ubyte* sp;; *sp++) {...}

// first clause is a block statement
// last clause is a function literal, not a block statement
for({j = 2; int d = 3;} j + d < 7; {j++; d++;}) {...}

Note: Calling a function returning void is not deprecated even if the function does nothing. This is for generic code.

Formerly, they were always allocated with the Garbage Collector, making it unavailable in @nogc or -betterC code. This led to frequent use of the following workaround:

void main() @nogc
{
    int[3] buffer = [10, 20, 30];
    int[] arr = buffer[];
}

This can now be written in a single line:

void main() @nogc
{
    scope int[] arr = [10, 20, 30];
}

With the following limitations:

• The variable must be explicitly annotated scope, not just inferred scope
• The -preview=dip1000 must be passed, to prevent introducing memory corruption in legacy code.

• The array literal must be initializing the variable. Subsequent array literals assignments still use the GC.
• The array elements may not have a destructor

Some of these limitations might get lifted in the future.

When the condition evaluates to false, any subsequent expressions will each be converted to string and then concatenated. The resulting string will be printed out along with the error diagnostic.

enum e = 3;
static assert(false, "a = ", e);

Will print:

file.d(2): Error: static assert:  a = 3

Since DIP 1035 - System Variables has been accepted, variables marked @system may no longer be accessed from @safe code. To avoid code breakage, the compiler will start with emitting deprecation warnings. The preview switch will turn these into errors, and it will be enabled by default in a future release.

@system int* p;

struct S
{
    @system int i;
}

void main() @safe
{
    int x = *p; // error with `-preview=systemVariables`, deprecation otherwise

    S s;
    s.i = 0; // ditto
}

Note that currently this is limited to variables explicitly marked @system, inference of @system based on a variable's initializer is yet to be implemented.

The way this works:

1. The runtime now has 2 trace-related functions, one for allocating a traceinfo, and one for deallocating the traceinfo. Both are set via the same Runtime.traceHandler function. The second parameter that sets the deallocation function is optional (so existing code will not be affected).
2. When a Throwable is thrown, if the trace info is not yet set, the runtime uses the designated function to allocate a trace info. If the deallocation function is non-null, the function pointer is copied into the Throwable, into the new member infoDeallocator.
3. When the Throwable is destroyed, if the infoDeallocator member is set, it is called on the info member.

The default allocator and deallocator now uses C malloc and free to allocate and deallocate the TraceInfo. Almost everything was already nogc, except for the allocation of the TraceInfo object itself.

The benefits:

1. Stack traces can now be generated when run inside the GC collection routine.
2. InvalidMemoryOperationError now has a stack trace.
3. Little known is that even inside @nogc functions, throwing a Throwable actually was using the GC, that is no longer the case (by default).
4. Certain GC hangs have been fixed (see bug fixes listed below).

One possible drawback is that the TraceInfo is deallocated upon Throwable being finalized, leading to a potential dangling pointer situation. If you do copy the info out of the Throwable, makes sure to not keep it beyond the lifetime of the Throwable, or make sure to set the infoDeallocator member to null.

New float and double overloads of std.math.exponential.log, std.math.exponential.log10, std.math.exponential.log1p, std.math.exponential.log2, and std.math.exponential.logb have been added to Phobos with proper 'software' implementations in the corresponding precision. Furthermore, std.math.exponential.logb is now pure.

While this may result in a slowdown in some cases for DMD, the overall speed-up factor for GDC and LDC is over 3x, for both double and float.

This also implies less precise results, especially in single-precision, so if your code depended on more accurate results via 80-bit intermediate precision, you'll have to cast the argument(s) explicitly now.

If you use unicode.c or unicode.Other (case insensitive) from std.uni, you should mitigate or fix your codebase.

This change makes it match the Unicode Techical Report #44. Unfortunately if you are already using it with its previous wrong values, this will break your code, below is a function which reflects the original values that you can use to mitigate against any breakage.

@property auto loadPropertyOriginal(string name)() pure
{
    import std.uni : unicode;

    static if (name == "C" || name == "c" || name == "other" || name == "Other")
    {
        auto target = unicode.Co;
        target |= unicode.Lo;
        target |= unicode.No;
        target |= unicode.So;
        target |= unicode.Po;
        return target;
    }
    else
        return unicode.opDispatch!name;
}

It is likely that this change will result in breakage in code and program usage. This is due to a number of factors, the tables being updated so significantly and the table generator not having all its changes commited throughout the years.

When Unique goes out of scope, any destructor will now be called. Previously the destructor was not called then.

static int i;

struct S
{
    ~this()
    {
        i++;
    }
}
{
    Unique!S u = new S;
    // S.~this now called here
}
assert(i == 1);

Note: Above, the struct destructor will also be called by the GC just before the memory for new S is reclaimed. Take care that any struct destructor used will handle being called again on the struct .init value.

The VisualD package version that the installer downloads hasn't been updated in years. This has been remedied by a version bump to 1.3.1, the latest release of VisualD.

The NSIS installer for Windows has the option "Add to PATH". Previously, only the 32 bit version of DMD was added to the PATH environment variable. Now, on Windows 64 bit, the 64 bit version of DMD will be selected from PATH.