変更ログ 2.063

最終的には非推奨となり、エラーが発生する。そのようなフィールドは をenumかstaticに変更すべきである。

将来のリリースでは、このようなフィールドの新しい動作が有効になる予定だ:

静的でない集約のフィールドは常にアドレス可能である。 つまり、それらはオブジェクト内のスペースを占有することになる:

struct S
{
    // 2.062では暗黙的にstaticであったが、現在は警告している。将来のリリースではstaticでなくなる。
    immutable int[] arr = [1, 2];

    // 同上
    const int[] arr2 = [1, 2];
}

これは、このような宣言に参照なしでアクセスしたコードはコンパイルできなくなることを意味する。this にアクセスするコードはコンパイルできなくなる。さらに、このようなフィールドを持つ に依存していたコードも修正しなければならない:

struct S
{
    immutable int[] arr = [1, 2];
}

void main()
{
    auto x = S.arr;  // 将来のリリースではエラーとなり、'arr'は'this'参照を必要とする。

    // 2.062と2.063では、Sはサイズ1である。将来のリリースでは、これは変更され、以下のstatic assertが通るようになる。
    static assert(S.sizeof == size_t.sizeof + size_t.sizeof);  // ptr + length for the array
}

フィールドを再び静的にするには、単にstaticキーワードを使えばよい。あるいは フィールドをenum にしてマニフェスト定数にする:

struct S
{
    static immutable int[] arr = [1, 2];
    enum arr2 = [1, 2];
}

ただし、配列であるマニフェスト定数は、各使用時に割り当てられることに注意されたい、 の代わりにstatic を使用することを好むかもしれない。

根拠: マニフェスト定数は配列である:

const/不変のフィールドかどうか、イニシャライザを持つかどうかに基づいて、フィールドを暗黙的に静的にすることは混乱を招く。static キーワードを使用すると、どのフィールドも明示的に静的にすることができる。

修飾されたコンストラクタは、const/immutable/shared 集約オブジェクトがインスタンス化されるときに呼び出される。 がインスタンス化されるときに、修飾されたコンストラクタが呼び出されるようになった:

import std.stdio;

class C
{
    this()           { writeln("1"); }
    this() const     { writeln("2"); }
    this() immutable { writeln("3"); }
    this() shared    { writeln("4"); }
}

void main()
{
    auto a = new C;           // "1"を書き込む
    auto b = new const C;     // "2"を書き込む
    auto c = new immutable C; // "3"を書き込む
    auto d = new shared C;    // "4"を書き込む
}

この結果、immutable またはshared コンストラクタ "しか持たない集合体は、変更可能なオブジェクトのインスタンス化に使用できなくなる:

class C
{
    this() immutable { }
    this() shared { }
}

void main()
{
    auto c1 = new C;           // 不許可
    auto c2 = new immutable C; // OK
    auto c3 = new shared C;    // OK
}

一方、shared またはimmutable コンストラクタを持たない集合体は、それぞれ または オブジェクトを構築するために使用できなくなる。 を持たない集合体は、それぞれshared またはimmutable オブジェクトを構築するために使用できなくなる:

class C
{
    this() { }
}

void main()
{
    auto c1 = new C;           // OK
    auto c2 = new immutable C; // 不許可
    auto c3 = new shared C;    // 不許可
}

しかし、集合体がpure コンストラクタを持つ場合、任意の型コンストラクタでオブジェクトを構築するために使用できる:

class C
{
    this() pure { }
}

void main()
{
    auto c1 = new C;  // OK
    auto c2 = new immutable C;  // OK
    auto c3 = new shared C;  // OK
}

以前のリリースでは、配列のような一部の構造体メンバは比較操作でビット単位で比較されていた。 これが構造体比較に変更された:

struct S
{
    char[] data;
}

void main ()
{
    auto s1 = S("foo".dup);
    auto s2 = S("foo".dup);

    assert(s1.data !is s2.data);  // どちらもユニークなデータである

    assert(s1 == s2);   // 2.063では合格
    assert(s1.data == s2.data);  // 上記と同等
}

opEquals 関数が存在しない場合、コンパイラーは式を書き換える。 s1 == s2 をs1.tupleof == s2.tupleof に書き換える。.tupleof 式の比較は、2.063リリースのDに追加された機能である。 式の比較も2.063リリースのDに追加された機能である。

配列コピー操作の右辺では、スライス構文を使用する必要がある:

void main()
{
    int[][2] x;
    int[] y;
    int[] z;

    x[] = z;    // z (ポインタ + 長さ)をxに2回コピーする
    y[] = z;    // zの各要素をyにコピーする(コンパイラは警告を出す)
}

もしユーザーがそのようなコードを書くつもりなら、ソース配列とターゲット配列の両方にスライス構文を使わなければならない:

void main()
{
    int[][2] x;
    int[] y;
    int[] z;

    y[] = z[];  // zの各要素をyにコピーする(警告は出ない)
}

根拠:このような理由で、このような決断を下したのである:

理由:コンパイラは、コピー操作が恣意的に高価であることを警告する。

型をその型の値として関数に渡すことができなくなった:

T[] foo(T)(T t)
{
    return null;
}

void main()
{
    alias int Int;

    // 以前は動作していた(エイリアスを使った場合のみ)、現在はコンパイラーエラー
    alias typeof(foo(Int)) IntArray;
}

ユーザーが特定の型の引数を渡したい場合は、.init " プロパティを使用することができる:

T[] foo(T)(T t)
{
    return null;
}

void main()
{
    alias typeof(foo(int.init)) IntArray;  // OK
}

根拠:このような理由で、このような決断を下したのである:

理由:特殊な文脈で型を "式"として扱うことは混乱を招くだけである。 その代わりに、.init " プロパティをそのような目的に使うことができる。

foreach範囲のインデックス変数は、デフォルトで値型になった:

void main()
{
    size_t count;
    foreach (n; 0 .. 10)
    {
        ++n;
        ++count;
    }
    assert(count == 10);  // 合格
}

もしユーザーがインデックス変数を変更したい場合は、ref キーワードを使わなければならない:

void main()
{
    size_t count;
    foreach (ref n; 0 .. 10)
    {
        ++n;
        ++count;
    }
    assert(count == 5);
}

根拠:このような理由で、このような決断を下したのである:

インデックス変数を暗黙的にref にすると、追跡が困難なバグが発生する可能性がある。

連想配列のエントリーは、代入される前にデフォルトで初期化されていた:

void main()
{
    int[int] aa;
    aa[1] = aa[1] + 1;   // 2.062ではエラーはスローされなかった
    assert(aa[1] == 1);  // 2.062では動作していた
}

2.063では、存在しないエントリーにアクセスするとRangeErrorがスローされるようになった:

void main()
{
    int[int] aa;
    aa[1] = aa[1] + 1;   // 2.063ではRangeErrorがスローされる
}

根拠:このような理由で、このような決断を下したのである:

代入時のデフォルト初期化はバグの原因になる。

メソッドのオーバーライドで、ベース・メソッドの const 属性が継承されなくなった:

class A
{
    void foo() const { }
}

class B : A
{
    // 2.062では動作していた、現在はエラー
    override void foo() { }  // 'const'がないことに注意
}

ユーザーがconstメソッドをオーバーライドしたい場合は、オーバーライドするメソッドをconstとしてマークしなければならない。 メソッドをconstとしてマークしなければならない:

class A
{
    void foo() const { }
}

class B : A
{
    override void foo() const { }  // OK
}

この機能により、メソッドの定数に基づいて新しいオーバーロードを導入することができる:

class A
{
    void foo() const { }
}

class B : A
{
    // 新しいオーバーロードを導入する(オーバーライドではない!)
    void foo() { }

    // 上記のオーバーロードが導入された場合、ユーザーは以下のいずれかを行わなければならない:
    // a: 関数のハイジャックを防ぐため、constオーバーロードを再度導入する
    alias super.foo foo;  // これをしないとコンパイラーエラーになる

    // もしくはb: 適切に型付けされたオーバーライドを提供する:
    override void foo() const { }
}

以前は次のようなコードが許されていた:

void f(int[] function() del)
{
    assert(!del());  // 失敗
}

typeof(null) g() { return null; }

void main()
{
    f(&g);
    f(() => null);
}

しかし、暗黙の変換は間違ったコードを生成してしまう。 これを回避するには、return型が適切に型付けされていることを確認する、 あるいは、ラムダ式の戻り値式で(T[]).init :

void f(int[] function() del)
{
    assert(!del());  // 合格
}

int[] g() { return null; }  // 戻り値の型を修正した

void main()
{
    f(&g);  // OK
    f(() => (int[]).init);  // OK
}

テンプレートThisパラメータを使うことで、this のメンバ関数の修飾子を推測できるようになった。 関数に推論できるようになった:

struct S
{
    void foo(this T)()
    {
    }
}

void main()
{
     immutable S s;
     s.foo();  // S.fooを不変にする
}

配列スライスはもはやl値ではない。これは、スライスからアドレスを取ることができなくなったことを意味する。 スライスは関数にrefで渡すことはできない:

void foo(ref int[] arr) { arr = new int[10]; }

void main()
{
    int[] arr;
    foo(arr);  // OK
    assert(arr.length == 10);

    foo(arr[]);  // 2.063では不許可、スライスはr値である
    auto ptr = &arr[1..2];  // 2.063では不許可、r値のアドレスを取ることができない
}

これを回避するには、スライスの再割り当てやサイズ変更が必要なく、その内容を読み取ったり変更したりするだけでよい場合は、関数にr値を取らせるようにすればよい。 を取るようにすればよい。 そうでない場合は、l値とr値の両方を受け取る関数にすればよい。 の引数をauto ref :

void take(int[] arr) { }
void takeRef(ref int[] arr) { }
void takeAutoRef(T)(auto ref T[] arr) { }

void main()
{
    int[] arr = [1, 2, 3, 4];
    take(arr);          // OK
    takeRef(arr);       // OK
    takeAutoRef(arr);   // OK

    int[] arr2 = arr[1 .. 2];
    take(arr2);         // OK、arr2は変数である
    takeRef(arr2);      // 同上
    takeAutoRef(arr2);  // 同上

    take(arr[1 .. 2]);         // OK
    takeRef(arr[1 .. 2]);      // エラー、r値を参照渡しできない
    takeAutoRef(arr[1 .. 2]);  // OK
}

根拠:このような理由で、このような決断を下したのである:

理由:スライスを参照渡しすることは、呼び出し先でそのようなスライスを再割り当てまたはサイズ変更する際に観測可能な効果がなかった。 従って、そのようなスライスはデフォルトでr値にすべきである。 例えば、以下のコードは以前は許可されていたが、現在はコンパイル時のエラーとなる:

void reAssign(ref int[] arr) { arr = new int[2]; }
void reSize(ref int[] arr)   { arr.length = 10; }

void main()
{
    int[] arr = [1, 2, 3, 4];

    reAssign(arr[0 .. 4]);  // 再割り当ては、呼び出し元で観測可能な効果をもたらさない
    assert(arr == [1, 2, 3, 4]);

    reSize(arr[0 .. 4]);    // サイズ変更は呼び出し元で観測可能な効果を持たない
    assert(arr.length == 4);
}

静的でないフィールドへのアクセスは、以前は多くのコンテキストで許可されていたが、現在はいくつかのコンテキストに限定されている:

- offsetof init その他の組み込みプロパティは許可されている:

struct S { int field; }

void main()
{
    auto a = S.field.offsetof;  // OK、statically known
    auto c = S.field.max;       // 同上
    auto d = S.field;           // 不許可、`this`参照はない
}

- 非静的フィールドの静的メソッドを呼び出す場合:

struct Foo
{
    static struct Bar
    {
        static int get() { return 0; }
    }

    Bar bar;
}

void main()
{
    static assert(Foo.bar.get() == 0);  // OK、`typeof(Foo.bar).get()`と等価である
}

- を使用して暗黙的に静的フィールドにアクセスする場合は、以下のようになる。 alias this式を使って暗黙的に静的フィールドにアクセスする:

struct Foo
{
    static struct Bar
    {
        static int get() { return 0; }
    }

    Bar bar;
    alias bar this;
}

void main()
{
    static assert(Foo.get() == 0);  // OK、'typeof(Foo.bar).get()'と等価である
}

配列の暗黙のポインタ変換は非推奨の機能だった:

void foo(int* p) { }

void main()
{
    int[] arr = [1, 2];
    foo(arr);   // コンパイル時に-dスイッチが使用されていればOK
}

この機能は現在完全に削除されている。回避策としては .ptr プロパティを使うか、明示的に最初の要素へのポインタを渡すことである:

void foo(int* p) { }

void main()
{
    int[] arr = [1, 2];
    foo(arr);      // コンパイルエラー
    foo(arr.ptr);  // OK
    foo(&arr[0]);  // OK
}

オブジェクトや配列に対するnew 、配列に対するdup のような式が、一意であると推測できるようになった。 これにより、コンパイラーはこのような式を暗黙のうちにimmutableに変換することができる:

class C { }

void main()
{
    immutable int[] arr1 = new int[](3);   // OK
    immutable int[] arr2 = [1, 2, 3].dup;  // 2.063ではOK
    immutable C[] arr3 = [new C, new C].dup;  // 2.063ではOK
}

void の静的配列はユーザー・コードで初期化できなかった:

void main()
{
    void[2] varr1;  // 2.062ではエラー
    void[2] varr2 = (void[2]).init;  // 2.062ではエラー
    void[2] varr3 = void;  // 2.062ではOK
}

2.063では、明示的なイニシャライザーが使用できる:

void main()
{
    void[2] varr1;  // 2.063ではまだエラー
    void[2] varr2 = (void[2]).init;  // 2.063ではOK
    void[2] varr3 = void;  // 2.063ではOK
}

.init プロパティは、配列を実質的にゼロ初期化する。

根拠:配列はゼロ初期化される:

理由:静的ボイド配列に特化することなく、一般的なコードで.init 。 を使用できるようにするためである。

集約型が複数の不変量を持つ場合、不変量の本体は単一の不変量関数にマージされ、実行される。 にマージされ、順番に実行される。1つのインバリアント内のコードは、コードやインバリアントを参照することはできない。 のコードは、別の不変量のコードやデータを参照できないことに注意すること:

struct S
{
    int x;

    void foo() { }

    invariant()
    {
        int local;
        assert(x != 0);
    }

    invariant()
    {
        // local = 1;  // 変異体はもう一方の変異体にアクセスできない
        assert(x % 2 == 0);
    }
}

void main()
{
    S s = S(2);
    s.foo();  // パブリック関数を呼び出すと、両方の変数が順番にトリガーされる
}

いくつかの属性を持つ関数がテンプレート化された集約をインスタンス化する場合、そのメンバ関数はそれらの属性を推論する、 ある属性を持つ関数がテンプレート化された集約をインスタンス化する場合、そのメンバ関数はそれらの属性を推論する:

struct S(T)
{
    T square(T x)
    {
        return x * x;
    }
}

void main() pure
{
    S!int s;  // S!int.squareが純粋になり、main()から呼び出せるようになる
    assert(s.square(2) == 4);  // OK
}

場合によっては is式 が識別子を必要とする場合があった:

void main()
{
    alias AA = string[int];

    static if (is(AA _ == V[K], V, K))
    {
        pragma(msg, _);  // string[int]を表示
        pragma(msg, K);  // intを表示
        pragma(msg, V);  // stringを表示
    }
}

識別子はもはや必要ないので、上記は次のように書き換えることができる:

void main()
{
    alias AA = string[int];

    static if (is(AA == V[K], V, K))
    {
        pragma(msg, AA); // string[int]を表示
        pragma(msg, K);  // intを表示
        pragma(msg, V);  // stringを表示
    }
}

あるコンテキストでは、コンパイラーは動的配列や配列のスライスのサイズを知っている。 このような場合、コンパイラは同じサイズの静的配列への暗黙の変換を許可する:

void foo(int[4] x) { }

void main()
{
    int[] arr = [1, 2, 3, 4, 5, 6, 7, 8];
    foo(arr[0 .. 4]);  // OK
}

別の例では、文字列が静的配列への参照に変換される:

string str = "aaaabbbbccccdddd";

void foo(ref const(char)[16] buf)
{
    assert(buf.ptr is str.ptr);
}

void main()
{
    foo(str[0..16]);  // OK
}

制限事項がある:

- この機能は、スライスのサイズを仮定するのが妥当な複雑な式ではまだ使えない。 スライスの大きさを仮定するのが妥当であるような複雑な式ではまだ機能しない:

void foo(int[4] x) { }

void main()
{
    int[] arr = [1, 2, 3, 4, 5, 6, 7, 8];
    foreach (i; 0 .. 4)
    {
        foo(arr[i .. i + 4]);  // 未サポート
    }
}

タプル変数をvoid初期化できるようになった:

template Tuple(T...)
{
    alias T Tuple;
}

void main()
{
    Tuple!(int, int) tup1 = void;  // OK
}

このような初期化では、タプルの値は未定義である。

以前は、テンプレート制約は継承リストの前にしか置けなかった。 テンプレート制約を継承リストの後に置くことができるようになった:

class Foo(T1, T2)
    if (is(T1 == int) && is(T2 == string)) : Base
{
}

この制限は解除され、書けるようになった:

class Foo(T1, T2) : Base
    if (is(T1 == int) && is(T2 == string))
{
}

例:

struct Tuple(T...) { T field; alias field this; }

void main()
{
    auto tup1 = Tuple!(int, int)(1, 2);
    auto tup2 = Tuple!(int, int)(1, 2);
    auto tup3 = Tuple!(int, int)(1, 3);

    assert(tup1 == tup2);  // 2.063以降で動作
    assert(tup1 != tup3);  // 2.063以降で動作
}

これは、std.traitのParameterStorageClassTuple インスタンスを比較できるようになったことも意味する:

import std.traits;

void func1(ref int x, ref int y) { }
void func2(ref float x, ref float y) { }

void main()
{
    alias Storages = ParameterStorageClassTuple;
    assert(Storages!func1 == Storages!func2);
}

それに加えて、組み込みの.tupleof 式を使えば、集約のフィールドを簡単に比較することができる:

struct S
{
    char[] a, b;

    // この型の別のインスタンスに対する等値テストを実装する。
    bool opEquals(S rhs) { return this.tupleof == rhs.tupleof; }
}

void main()
{
    S s1 = S("a".dup, "b".dup);
    S s2 = S("a".dup, "b".dup);
    assert(s1 == s2);
}

これにより、別の型のインスタンスに対する構造的な等質性テストを実装することもできる。 を実装することもできる:

struct S1
{
    char[] a, b;

    // 他の型Tに対する構造的等値テストを実装する
    bool opEquals(T)(T rhs) { return this.tupleof == rhs.tupleof; }
}

struct S2
{
    string x, y;
}

void main()
{
    auto s1 = S1("123".dup, "456".dup);
    auto s2 = S2("123", "456");
    assert(s1 == s2);
}

タプルはスライスできるので、この機能を使ってタプルのサブセットを比較することができる:

struct S
{
    int a, b, c, d, e;

    bool opEquals(S rhs)
    {
        // a, b, d, eを比較する
        return this.tupleof[0..2] == rhs.tupleof[0..2] &&
               this.tupleof[3..5] == rhs.tupleof[3..5];
    }
}

void main()
{
    S s1 = S(1, 2, 0, 3, 4);
    S s2 = S(1, 2, 1, 3, 4);
    assert(s1 == s2);
}

constコンストラクタでフィールドを初期化できるようになった。 コンストラクタでフィールドを初期化できるようになった:

struct S
{
    bool field = true;

    this(int v) const
    {
        field = false;  // OK
    }
}

新しいisNested形質によって、以下のことが可能になる。 新しいisNested traitは、集約や関数がコンテキスト・ポインタを含んでいるかどうかを発見することができる:

void main()
{
    int x;

    struct S1 { void f() { x++; } }
    static struct S2 { }

    void f1() { x++; }
    static void f2() { }

    static assert(__traits(isNested, S1));
    static assert(__traits(isNested, f1));
    static assert(!__traits(isNested, S2));
    static assert(!__traits(isNested, f2));
}

ローカル・インポートによって利用可能になった関数は、Uniform Function Call Syntaxを使用する際にピックアップされるようになった:

module foo;
string concat(string arg1, string arg2) { return arg1 ~ arg2; }

module test;
void main()
{
    import foo;
    assert("foo".concat("bar") == "foobar");  // UFCSが動作するようになった
}

この機能は、アグリゲート内のインポートでも機能する。ローカル・インポートは、モジュール・スコープのインポートよりも優先順位が高いことに注意されたい。 よりも優先される。

新しい キーワードが追加された。 追加された。__FILE__ 、__LINE__ とともに、コードのデバッグに役立つ完全な機能セットを形成している。 を形成している:

module test;
import std.stdio;

void test(string file = __FILE__, size_t line = __LINE__, string mod = __MODULE__,
          string func = __FUNCTION__, string pretty = __PRETTY_FUNCTION__)
{
    writefln("file: '%s', line: '%s', module: '%s',\nfunction: '%s', pretty function: '%s'",
             file, line, mod, func, pretty);
}

int main(string[] args)
{
    test();
    return 0;
}

上記のように出力される:

file: 'test.d', line: '13', module: 'test',
function: 'test.main', pretty function: 'int test.main(string[] args)'

module test;

/// sum関数
deprecated int sum(int x, int y) { return x + y; }

デフォルトでは、マクロは引数に展開される。これは、例えばユーザーによってオーバーライドすることができる:

macros.ddoc:

DEPRECATED=<del>$0</del>

上記のddocファイルは、ドキュメンテーションを作成するときに使用できる:

$ dmd -D -o- test.d macros.ddoc

シンボル宣言の後に続くドキュメント化されたunittestは、DDOCドキュメントを生成する際に、シンボルの例セクションを生成するために使用されるようになった。 の例セクションを生成するために使われるようになった。例:」と表示される:

/// sum関数
int sum(int x, int y) { return x + y; }

///
unittest
{
    assert(sum(2, 2) == 4);
}

unittestの本体はsum関数のドキュメントの一部となる。これにより 関数の実装者は、常にその例を最新に保つことができる。

詳しくは ドキュメントページ を参照のこと。

-main ・スイッチは、主にライブラリーのunittest時に便利である:

module test;

int sum(int a, int b) { return a + b; }
unittest
{
    assert(sum(2, 2) == 4);
}

上記のライブラリでは、unittestsを実行するためにmain() 関数が必要になる、 -main :

$ dmd -unittest -main -run test.d

-cov スイッチにオプションのパーセンテージ設定が追加された。 これは、カバレッジが指定された要件を満たさない場合に実行ファイルをエラーにするものである:

module test;

void test1() { int x = 5; }
void test2() { int x = 5; }
void test3() { int x = 5; }

void main()
{
    test1();
    test2();
}

カバレッジテストの例:

$ dmd -cov=90 test.d
$ test
Error: test.d is 80% covered, less than required 90%

新しいpragma(mangle, ...) ディレクティブにより、任意のシンボルにカスタム・マングリングを設定できる:

pragma(mangle, "module") extern(C) void module_();

上記は、通常 "module"という名前のC関数にリンクすることを可能にする。 module "は予約されたDキーワードなので、通常は直接リンクすることはできない。

scoped 呼び出しの型を取得するためにstd.traits.ReturnType トレイトを使っていたユーザーコードは、代わりに 演算子を使うように変更しなければならない。 代わりにtypeof 演算子を使うように変更しなければならない:

class A
{
    this() {}
    this(int) {}
}

class B
{
    // ReturnType!(scoped!A) a;  // 2.063では許可されていない
    typeof(scoped!A()) a;        // 書き直され、2.063ではコンパイルされる

    this()
    {
        a = scoped!A(1);  // 2.062ではコンパイルされなかったが、2.063で使用された構文で動作する。
    }
}

この変更の理由は、クラスが複数のコンストラクタを持つ場合、ReturnType "トレイト"が間違った型を取得してしまい、フィールドの初期化に失敗してしまうからである。 が複数のコンストラクタを持つ場合、間違った型を取得してしまい、フィールドの初期化に失敗してしまうからである。

新しい実装のもう1つの利点は、scoped 、ユーザビリティのためにエイリアスを作成できるようになったことである:

class A
{
    this(int) { }
}

void main()
{
    alias scoped!A scopeA;
    auto a = scopeA(1);
}

新しい std.process新しいモジュールでは、カスタムパイプリダイレクトでプロセスを呼び出す機能が導入されている、 プロセスの終了を待つ機能、プロセスを kill する機能などが導入されている。機能の全リストは は std.processドキュメントにある。

例:":

void main(string[] args)
{
    bool flag = true;
    getopt(args, &flag);
}

--flag=false 経由で呼び出されると、flag をfalse に設定する。

子スレッドからオーナー・スレッドにメッセージを送るのが簡単になった。 オーナー・スレッドにメッセージを送るのが簡単になった。ownerTid "プロパティを使って、オーナー・スレッドのTid識別子を取得するだけだ。 スレッドのTid識別子を取得する:

void fun()
{
    string res = receiveOnly!string();
    assert(res == "Main calling");

    ownerTid.send("Child responding");  // new
}

void main()
{
    auto child = spawn(&fun);
    child.send("Main calling");

    string res = receiveOnly!string();
    assert(res == "Child responding");
}

オーナースレッドが終了した場合、子スレッドからownerTidにアクセスすると、。 にアクセスすると、TidMissingException がスローされる。