変更履歴: 2.109.0

このようなエイリアスは、実際にはインスタンスの型のメンバをエイリアスするものであり、 インスタンスのメンバ自身をエイリアスするものではない。これは混乱を招く可能性があり、現在はエラーとなっている。 代わりに、型のメンバをエイリアスする。

struct Foo
{
    int v;
    void test(Foo that) const
    {
        alias a = this.v; // OK
        alias b = that.v; // エラー、代わりに`typeof(that).v`を使用する
        assert(&a is &b); // 合格
        assert(&b !is &that.v);
    }
}

struct Bar
{
    Foo f;
    alias v = f.v; // エラー、`typeof(f).v`を使用する
}

追加:

• プロパティ.bitoffsetof でビットフィールドの開始ビット番号を取得する

• プロパティ.bitwidth でビットフィールドのビット数を取得する

• __traits(isBitfield, symbol) フィールドシンボルがビットフィールドである場合は true を返す

特殊関数__ctfeWrite は、pragma(msg, ...) と同様に、 CTFE中にメッセージを書き込むために使用できるようになった。メッセージがユーザにどのように提示されるかは処理系定義である。 推奨される方法は、 メッセージをstderr (標準エラーストリーム)に 出力することである。この関数はobject.d で使用可能であり、const(char)[] に暗黙的に変換できる任意の値を受け入れる。 "implementation defined"処理系定義

例えば:

int greeting()
{
    __ctfeWrite("Hello from CTFE. Today is ");
    __ctfeWrite(__DATE__);
    __ctfeWrite("\n");
    return 0;
}

enum forceCTFE = greeting();

このプログラムをコンパイルすると、以下の出力が生成される。

Hello from CTFE. Today is <current date>

デフォルトでは、コンパイラは20個のエラーメッセージを表示した時点で停止する。ただし、例えば-verrors=50 や-verrors=0 を指定して無制限にすることも可能である。 このエラー表示の制限は、非推奨メッセージにも適用されるようになったため、まだすべての非推奨を修正していない大規模なプロジェクトをコンパイルする場合でも、何百もの非推奨メッセージがコマンドラインに表示されることはない。

deprecated void f()
{
}

void main()
{
    f();
    f();
    f();
    f();
}

> dmd -verrors=3 app.d
app.d(7): Deprecation: function app.f is deprecated
app.d(8): Deprecation: function app.f is deprecated
app.d(9): Deprecation: function app.f is deprecated
1 deprecation warning omitted, use -verrors=0 to show all

-HC スイッチを使用すると、extern(C) およびextern(C++) 関数に加えて、extern(Windows) およびextern(System) 関数も .h ファイルに出力される。

例 D モジュール:

extern(Windows) int hello()
{
    return 0;
}

extern(System) int myFriend()
{
    return 0;
}

-HC スイッチ付きの出力:

// (フルヘッダー省略)

#ifndef _WIN32
#define EXTERN_SYSTEM_AFTER __stdcall
#define EXTERN_SYSTEM_BEFORE
#else
#define EXTERN_SYSTEM_AFTER
#define EXTERN_SYSTEM_BEFORE extern "C"
#endif

int32_t __stdcall hello();

EXTERN_SYSTEM_BEFORE int32_t EXTERN_SYSTEM_AFTER myFriend(x);

配列の長さは、以下の場合はコンパイル時に判明する。

• 配列がリテラルである場合
• 配列がスライス式であり、その上限がコンパイル時に既知である

配列a の場合、インデックスの型は任意の整数型I であり、a.length <= I.max 。

その他のケースはまだ実装されていない。

foreach_reverse が使用された場合、デリゲートによって返された結果の逆走査をコンパイラが実装しようとしなかった。 その結果、コードが 読みづらくなる可能性があったため、長年にわたって非推奨とされていた。foreach_reverse をデリゲートと共に使用すると、現在エラーとなる。

現在、DとImportCの両方について、c99 、c11 、UAX31 (C23)およびall (最も制限の少ないセット)から選択できる。

これは、-identifiers=<table> および ImportC については-identifiers-importc=<table> を使用して行うことができる。

Dのデフォルトのテーブルは現在、all に設定されており、ImportCはc11 に設定されている。 以前は、DとImportCの両方がc99 のテーブルを使用していた。

Dのテーブルは、後日、UAX31に切り替わる予定である。これは2.117で行われるべきである。 もし、現在、c99 の特定の文字を使用しており、変更したくない場合は、all に戻すこともできる。 しかし、そのような必要が生じることはまずないはずである。

ユニバーサル文字名がサポートされるようになったため、\uXXXX および\UXXXXXXXX の構文を使用できるようになり、X が識別子の一部として16進数で表されるようになった。

DigitalMars sppnはC99より新しいものはサポートしていない。 制限があることが知られており、これらの範囲外のUnicode文字を使用するとエラーが発生する。

ライブラリへのリンクを忘れたり、.dファイルをコマンドラインにリストアップしたり、main 関数を含めたりすることは珍しくない。 例:

module app;

unittest
{
    import assertions;
    assertEquals('D', 'D');
}

module assertions;

void assertEquals(char a, char b)
{
    assert(a == b);
}

以下のようにコンパイルする場合:

> dmd -unittest app.d

コンパイラはエラーを検知しないが、リンク時にシンボルが欠落している。 以前は、シンボル名が文字化けした不可解なリンカーエラーが発生していた。

/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../lib/Scrt1.o: in function `_start':
(.text+0x1b): undefined reference to `main'
/usr/bin/ld: app.o: in function `_D3app16__unittest_L5_C1FZv':
app.d:(.text._D3app16__unittest_L5_C1FZv[_D3app16__unittest_L5_C1FZv]+0xc): undefined reference to `_D10assertions12assertEqualsFaaZv'
collect2: error: ld returned 1 exit status

経験豊富なユーザーであれば、シンボルをデマングルして読みやすくする方法を知っているかもしれない。

> echo _D10assertions12assertEqualsFaaZv | ddemangle
void assertions.assertEquals(char, char)

しかし、毎回手作業でやるのは不便だ。 コンパイラがリンカプログラムを呼び出すと、その出力が読み込まれ、未定義シンボルエラーがスキャンされ、名前がデマングリングされる。

Error: undefined reference to main
Error: undefined reference to void assertions.assertEquals(char, char)
       referenced from void app.__unittest_L5_C1()
       perhaps define a void main() {} function or use the -main switch
       perhaps .d files need to be added on the command line, or use -i to compile imports
Error: linker exited with status 1

これにより、コマンドの修正が容易になる。

> dmd -unittest -main -i app.d

現在サポートされているリンカーは、ld、bfd、gold、mold、Microsoft LINK である。 お使いのリンカーのエラーが検出されない場合は、問題を報告してほしい。

PE-COFFをWindowsのデフォルトとしてサポートするようになってから2年が経過したが、OMFのサポートは現在削除されている。

これには、スイッチ (-m32omf) も含まれる。

新しいモジュールcore.sys.linux.sys.mount は、 Linux のヘッダー<sys/mount.h> にある定義に対応する

DガベージコレクタのcollectNoStack 関数は、 スレッドスタックやスレッドローカルストレージのルートを使用せずに、収集を実行した。 このメカニズムを実行する危険性は、 スレッドからの参照のみを持つメモリブロックが、スレッドが実行中であり、 メモリを使用している可能性があるにもかかわらず、収集される可能性があることである。 "関数""関数"

この関数が呼び出されるのは、GCの終了時だけである。GCの 終了時には、GCが破棄されようとしているため、できるだけ多くの デストラクタを実行したい。しかし、GCによって割り当てられたメモリをスレッドが使用している場合、 そのメモリをクリーンアップしても問題の解決にはならない。GCがメモリをクリーンアップした後にクラッシュするか、 GCが破棄された後にクラッシュするかの

この関数の本来の目的(D1より)は、 このメカニズムはシングルスレッドのプログラム(そしてもちろん、プログラム終了時)でのみ使用されていたため、小規模なテストプログラムで GC が確実にクリーンアップされるようにすることが、この関数の当初の目的であった。 また、当時、 D1 は 32 ビットであり、偽ポインタは今よりもずっと一般的であった。 スタックのスキャンを回避することで、クリーンアップ時の一見ランダムな動作を回避できる。 しかし、以下に示すように、データを確実に 常にクリーンアップする

今日では、そのような関数が呼び出される可能性ははるかに高い。 そのような関数が呼び出されると、実行中のスレッドすべてにおいて、使用後解放メモリ破壊が即座に開始される。 したがって、私たちはその機能を完全に削除し、標準のGCクリーンアップ(スタックのスキャン など)のみを行う。プログラム終了時のGCクリーンアップの保証が少なくなることで、潜在的な危険性が一つ減るという利点がある。

さらに、現在のGCは有効なスタックの場所について少し賢くなっているため、 ブロックが未確定のままになる可能性はさらに低くなっている。

これまで通り、GCは実行終了時にすべてのブロックをクリーンアップすることを保証するものではない。 以前はブロックのクリーンアップを行っていたコードの動作が変更され、 クリーンアップされなくなった場合でも、それは仕様内である。また、 すべてのブロックを確実にクリーンアップする動作を希望する場合は、--DRT-gcopt=cleanup:finalize の実行時構成オプションを使用することで、 スキャンを行わずにすべてのブロックをクリーンアップすることが

静的メソッドcore.thread.Thread.sleep は現在、@trusted としてマークされており、@safe のコードから直接呼び出すことができる。

std.process.Config.preExecDelegate はstd.process.Config.preExecFunction、 しかし、環境をキャプチャすることもできる。例えば:

import core.sys.linux.sys.prctl : PR_SET_PDEATHSIG, prctl;
import std.process : Config, execute;

void runProgram(int pdeathsig)
{
    execute(
        ["program"],
        config: Config(
            preExecDelegate: () @trusted =>
                prctl(PR_SET_PDEATHSIG, pdeathsig, 0, 0, 0) != -1,
        ),
    );
}

preExecFunction 後方互換性を維持するために保持されます。 と の両方が指定された場合、両方が呼び出されます。preExecFunction preExecDelegate