Change Log: 2.098.0

In D, the ternary operator (?:) has a higher precedence than the assignment operator (=), hence:

true ? stt = "AA" : stt = "BB"

actually means:

(true ? (stt = "AA") : stt) = "BB",

This is in line with C, and many other languages (except C++), but comes at a surprise to many, which is why this specific combination of ternary and assignment was deprecated in v2.082.0 (2018-09-01).

The deprecation instructs the user to use parenthesis to make the intent explicit, so the above snippet should read as:

true ? (stt = "AA") : (stt = "BB")

This deprecation period has now ended and the compiler will now issue an error for ambiguous code.

Using body to indicate the body of a function or method in the presence of contracts is now deprecated. Any leftover usage of body can be replaced with do. This replacement, introduced by DIP1003, has been available since DMD v2.075.0 (July 2017).

Since v2.084 it is no longer possible to bypass private imports by using fully-qualified names, this was deprecated in v2.071 but when fully-qualified names are used as a type (vs an expression) the code is accepted without any warning.

Starting with this release the compiler will now properly deprecate the previous omitted case.

The issue is best described in the following example:

import std.algorithm;

// deprecated in v2.071, error since v2.084
auto a = std.range.Take!(int[]); // Error: undefined identifier `range` in package `std`...

// now it's deprecated, will be error from v2.106
std.range.Take!(int[]) s;

If a less restrictive package attribute appeared within the scope of another package attribute, the more restrictive parent would override any explicit child visibility.

Example:

module pkg.foo;

package(pkg.foo):           // analogous to "private" or plain "package"

package(pkg) int bar();     // package(pkg) was being ignored

Starting from this version, the package visibility attribute is now always applied as long as it is valid. In the given example, this allows any module in the package pkg to import and use the symbol bar.

The syntax is pragma(mangle, str_or_decl [, str] ) declaration; where str_or_decl is either: a string expression to substitute the name of declaration; or a class, struct, or union declaration or template instance to use instead of declarations for mangling. If the optional second argument is present, use that as a name instead but keep the namespaces and template parameters of str_or_decl (if any).

This enables binding with functions that take classes by value or reference and to classes that are D keywords.

To bind C++'s std::function by value:

extern(C++, "std")
{
    template std_function(F)
    {
        pragma(mangle, "function")
        class std_function
        {
            // member variables and functions
        }
    }
}

template ScopeClass(C , string name)
{
    enum ns = __traits(getCppNamespaces,C);
    extern(C++, class) extern(C++,(ns))
    {
        pragma(mangle, C, name)
        struct ScopeClass
        {
            char[__traits(classInstanceSize, C)] buffer;
            // member variables and functions
        }
    }
}

alias FuncType = void function(int);
alias RawFuncType = typeof(*FuncType.init);
// Mangles as `void funk(std::function<void(int)> a)`
extern(C++) void funk( ScopeClass!(std_function!(RawFuncType)),"function") a );

D previously supported complex and imaginary versions of all floating point types as part of the language.

float a = 2;
ifloat b = 4i;
cfloat c = a + b;
assert(c == 2 + 4i);

However these types are too specialized to be a part of the core language, and the same functionalities can be implemented as part of a library type. As such, older versions of DMD provided the -transition=complex switch to warn when those builtin types were used. This transition phase has finished, and those deprecations are now turned on by default.

Users should use std.complex.Complex instead.

import std.complex;
float a = 2;
float b = 4;
auto c = complex(a, b);
assert(c == complex(2, 4));

The -transition=complex switch that previously turn on deprecation warnings no longer has an effect and has also been deprecated.

Up until this release, while (auto n = expression) was not supported, although the if counterpart: if (auto n = expression) compiled succesfully. Starting with the current compiler version, while (auto n = expression) is accepted, having the exact same semantics as:

while (true)
{
    if (auto n = expression)
    { /* loop body */ }
    else
    { break; }
}

A new flag '=' has been added to the format specifier, which allows to center the output:

assert(format!"|%=8d|"(1234) == "|  1234  |");

In case the output cannot be centered exactly it is moved slightly to the left if '-' flag is present too and to the right else:

assert(format!"|%=-8d|"(123) == "|  123   |");
assert(format!"|%=8d|"(123) == "|   123  |");

The function ImplicitConversionTargets in module std.traits has a design flaw: The list of conversion targets contains some, but not all unsafe conversion targets. To overcome this, a new function AllImplicitConversionTargets has been added and ImplicitConversionTargets has been deprecated.

The formatting posibilities of integers have been expanded to the specifiers that are typical for floating point numbers: Integers can now be formatted using %e, %f, %g and %a. The result is similar to the result expected for the corresponding floating point value.

assert(format!"%.3e"(ulong.max) == "1.845e+19");
assert(format!"%.3,3f"(ulong.max) == "18,446,744,073,709,551,615.000");
assert(format!"%.3g"(ulong.max) == "1.84e+19");
assert(format!"%.3a"(ulong.max) == "0x1.000p+64");

We noticed that the implementation of pow(f, -2) and f ^^ -2 with f being a floating point value, was buggy for some values of f. Unfortunately the fix implies small changes for other values for f (with exponent -2) too: The least significant bits of the result might differ from the current implementation. (This is due to the peculiarities of floating point numbers and cannot be avoided with reasonable means.)

To avoid problems, make sure, that your algorithms do not rely on the least significant bits of floating point calculations, for example by using isClose instead of ==.

enforceValidFormatSpec from std.format has been accidentally made public and will be removed from public view in 2.107.0.

formatElement from std.format has been accidentally made public and will be removed from public view in 2.107.0.

Please use instead of formatElement(sink, value, fmt):

import std.range : only;

sink.put(format!("%("~fmt~"%)")(only(value)));

unformatElement from std.format has been accidentally made public and will be removed from public view in 2.107.0.

Please use instead for strings and characters parseElement from std.conv and for all else unformatValue from std.format.read.

Previously FieldNameTuple returned AliasSeq!"" for interfaces as done for non-aggregate types like int, char*, ... . This behaviour was surprising because an instance of that interface may have members that just are not known at compile time.

FieldNameTuple will now return an empty AliasSeq!() for interfaces.

Previously Fields returned AliasSeq!(Interface) for interfaces as done for non-aggregate types like int, char*, ... . This behaviour was surprising because an instance of an interface may have members that just are not known at compile time.

Fields will now return an empty AliasSeq!() for interfaces.

Example:

import std.format : format;
import std.math : sqrt;

enum pi = format!"%s"(3.1415926f);
static assert(pi == "3.14159");

enum golden_ratio = format!"|%+-20.10E|"((1 + sqrt(5.0)) / 2);
static assert(golden_ratio == "|+1.6180339887E+00   |");

The implementation of formatting floating point numbers has been reworked. We made sure that working examples never allocate with the GC, however, we are still using exceptions which are GC managed. Therefore, code that uses formatting correctly will never allocate, but in the case of exceptions, the GC will be used to allocate the exception. We are working on DIP 1008 to solve this issue.

In the internals of std.format we replaced a call to snprintf of libc with routines written in D for formatting floating point values. These functions only work for floats, doubles, 64-bit-reals and 80-bit-reals (x87-reals) yet.

All other reals are handled by downcasting them to doubles before being formatted. This might result in a loss of precision in the output. Further, numbers larger than double.max will be formatted like double.max and numbers large than zero but smaller than the smallest positive double will be formatted like the smallest positive double. Likewise for negative values.

Nullable no longer implicitly converts to its member. This feature was problematic because a simple use of a value could invisibly cause an assertion due to type conversion. To restore the previous behavior, replace uses of a Nullable value n with n.get.

In the last years, the documentation of std.format was outdated little by little and therefore needed a complete rework. The whole package was reviewed and all documentations, including examples, improved and extended.

Some highlights:

• The grammar of the format string was updated.
• A detailed description of format specifiers was provided.
• Several examples on how to use the functions and the format strings were added.

The module std.format has been split into submodules:

• std.format.spec: Symbols concerning the format string, mainly the struct FormatSpec and the template singleSpec
• std.format.read: Symbols concerning reading input, mainly the template formattedRead and the template unformatValue
• std.format.write: Symbols concerning writing output, mainly the template formattedWrite and the template formatValue

All public symbols are still accessible using std.format as usual.

The module std.math has been split into submodules:

• std.math.constants: Mathematical constants, like PI.
• std.math.algebraic: Basic algebraic functions, like abs and sqrt.
• std.math.trigonometry: Trigonometric functions, like sin and cos.
• std.math.rounding: Functions concerned about rounding, like ceil and floor.
• std.math.exponential: Exponential and logarithmic functions, like pow, exp and log.
• std.math.remainder: Function calculating the remainder, like fmod.
• std.math.operations: Floating-point operations, like isClose, nextUp and fmin.
• std.math.traits: Floating-point introspection, like isNaN and isSubnormal.
• std.math.hardware: Hardware control: IeeeFlags and FloatingPointControl.

All public symbols are still accessible using std.math as usual.

std.algortihm.iteration.splitWhen is a variant of the existing std.algortihm.iteration.chunkBy function that does not require its predicate to be an equivalence relation, allowing it to be used in ways that chunkBy cannot. For example:

// Grouping by maximum adjacent difference:
import std.math : abs;
import std.algorithm;
auto r3 = [1, 3, 2, 5, 4, 9, 10].splitWhen!((a, b) => abs(a-b) >= 3);
assert(r3.equal!equal([
    [1, 3, 2],
    [5, 4],
    [9, 10]
]));

This would have an undefined result with chunkBy, because it requires that if pred(a,b) and pred(b,c) return true, pred(a,c) must also return true.

It had been deprecated in 2.077.0 in favor of std.datetime.stopwatch, which uses core.time.MonoTime and core.time.Duration.

It had been deprecated in 2.079 in favor of std.exception.enforce.

The sumtype package from code.dlang.org has been added to the standard library as std.sumtype.

It provides SumType, a generic discriminated union implementation that uses design-by-introspection to generate safe and efficient code, and is intended to serve as a replacement for the legacy std.variant.Algebraic.

Features of SumType include:

• Pattern matching.
• Support for self-referential types.
• Full compatibility with pure, @safe, @nogc, nothrow, and scope.
• No dependency on runtime type information (TypeInfo).
• Compatibility with BetterC.

Example usage:

import std.sumtype;
import std.math : isClose;

struct Fahrenheit { double degrees; }
struct Celsius { double degrees; }
struct Kelvin { double degrees; }

alias Temperature = SumType!(Fahrenheit, Celsius, Kelvin);

// Construct from any of the member types.
Temperature t1 = Fahrenheit(98.6);
Temperature t2 = Celsius(100);
Temperature t3 = Kelvin(273);

// Use pattern matching to access the value.
Fahrenheit toFahrenheit(Temperature t)
{
    return Fahrenheit(
        t.match!(
            (Fahrenheit f) => f.degrees,
            (Celsius c) => c.degrees * 9.0/5 + 32,
            (Kelvin k) => k.degrees * 9.0/5 - 459.4
        )
    );
}

assert(toFahrenheit(t1).degrees.isClose(98.6));
assert(toFahrenheit(t2).degrees.isClose(212));
assert(toFahrenheit(t3).degrees.isClose(32));

// Use ref to modify the value in place.
void freeze(ref Temperature t)
{
    t.match!(
        (ref Fahrenheit f) => f.degrees = 32,
        (ref Celsius c) => c.degrees = 0,
        (ref Kelvin k) => k.degrees = 273
    );
}

freeze(t1);
assert(toFahrenheit(t1).degrees.isClose(32));

// Use a catch-all handler to give a default result.
bool isFahrenheit(Temperature t)
{
    return t.match!(
        (Fahrenheit f) => true,
        _ => false
    );
}

assert(isFahrenheit(t1));
assert(!isFahrenheit(t2));
assert(!isFahrenheit(t3));

Transposed never worked as forward range.

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:

"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.