変更ログ 2.094.0

引数を2つ取る。最初の引数はシンボルまたは式でなければならない。 は、parent のメンバへのエイリアスなどのシンボルでなければならない。 member parent これはthis の逆である。 __traits(parent, member)の逆である。

struct A
{
    int i;
    int foo(int j) {
        return i * j;
    }
}

alias Ai = A.i;

void main()
{
    A a;

    __traits(child, a, Ai) = 3;
    assert(a.i == 3);
    assert(__traits(child, a, A.foo)(2) == 6);
}

DMDが配列リテラル要素の共通型を決定できない場合があった。 を決定できない場合があった。不一致の列挙型と、ミュータブル要素とイミュータブル要素のみを含む とimmutable要素のみを含むリテラルが正しく推論されるようになった。

少なくとも1つのインスタンス化を持つすべてのテンプレートが、標準の コンパイラ診断の標準書式を使って表示されるようになった。 宣言のポイントに簡単にナビゲートできるようになった。

この種のメッセージはすべて、一意のインスタンス化数の降順でソートされる。

フラグ引数list-instances が渡された場合(-vtemplates=list-instances など)、 テンプレートがインスタンス化された各場所が、インスタンス化の理由(暗黙的か明示的か)とともに表示される。 とともに表示される。

たとえば、main.d という名前のDソース・ファイルに

void foo(int I)() { }
void goo1(int I)() { }
void goo2(int I)() { goo1!(I); }

void test()
{
    foo!(1)();
    foo!(1)();
    foo!(2)();

    goo1!(1)();

    goo2!(1)();
}

-vtemplates=list-instances でコンパイルすると、次のように出力される。

main.d(1): vtemplate: 3 (2 unique) instantiation(s) of template `foo(int I)()` found, they are:
main.d(7): vtemplate: explicit instance `foo!1`
main.d(8): vtemplate: explicit instance `foo!1`
main.d(9): vtemplate: explicit instance `foo!2`
main.d(2): vtemplate: 2 (1 unique) instantiation(s) of template `goo1(int I)()` found, they are:
main.d(11): vtemplate: explicit instance `goo1!1`
main.d(3): vtemplate: implicit instance `goo1!1`
main.d(3): vtemplate: 1 (1 unique) instantiation(s) of template `goo2(int I)()` found, they are:
main.d(13): vtemplate: explicit instance `goo2!1`

生成されるC++ヘッダーは、 以外の宣言に遭遇したときにコメントを書いていた。 extern(C++) 。

// test.d
void foo() {}

// test.h
[...]
// リンケージのため関数test.fooを無視

これは生成されるヘッダー・ファイルの肥大化の原因となっていたが、現在は以下のようにカスタマイズできる。 HC= スイッチでカスタマイズできるようになった。 verbose (コメントを書く) とsilent (コメントを省く) のどちらかを受け付ける。デフォルトの はsilent に変更された。

注釈: ヘッダージェネレーターはまだ実験的なものである。 バグが発生した場合はバグトラッカーに報告してほしい。

デバッグコードを書くとき、関数ブロックがthrow 、 しかし、コンソールやログファイルへの書き込みなど、快適なデバッグ体験は通常、nothrow 。 DMDではすでに、debug 文の中でpure と@nogc をエスケープすることができた。 今回のリリースでは、例外をスローするコードもdebug 文から呼び出すことができる:

import std.stdio;
void main() nothrow
{
    debug writeln("Your throwing log statement.");
}

関数をpragma(inline, true) でマークすると、呼び出されたときに常にインライン化されるようになった。 されるようになり、インライン化できない場合はコンパイルエラーとなる。

pragma(inline, true) 、関数本体ではなく、関数内に埋め込まれる。 に埋め込まれている場合、それが常に有効になるとは限らない。(関数本体が呼び出される前に解析されるかどうかによる。 本体が呼び出される前に解析されるかどうかに依存する)。

pragma(inline, true) "でマークされた関数がインライン化できない場合、-wiコマンドラインスイッチが指定された場合のみ警告を発するようになった。 wiコマンドラインスイッチが与えられた場合のみ警告を発する。以前は が指定された場合のみ、警告を発するようになった。

基底クラスメソッドの暗黙的オーバーライドは、2.075.0で非推奨となった (2017-07-19リリース) で非推奨となった。 がPR 6731 によって修正された。

非推奨期間は終了し、以下のコードは今後常にエラーとなる:

class Base
{
    void myFunction();
    void myOtherFunction(void* ptr);
}

class Child : Base
{
    // エラー: 暗黙的に`Base.myFunction`をオーバーライドしている
    void myFunction() const;
    // エラー: 暗黙的に`Base.myOtherFunction(void*)`をオーバーライドしている
    void myOtherFunction(const void* ptr);
}

以前は、コンパイラは__vector 型を暗黙的に他の 型と変換することができた。 __vector 型と暗黙の変換が可能であった。

int4 x = 2;
float8 y = x;
short8 z = y / 3;

このリリースでは、__vector 型は、静的配列のように、暗黙的にそれ自身の修飾型かvoid型にのみ変換できるようになった。 それ自身の修飾子かvoidに暗黙的に変換されるだけである。

const int4 a = 5;
int4 b = a;         // OK、どちらもint4
void16 c = a;       // OK、同じサイズのvoidにキャスト
float4 d = b;       // エラー、暗黙的にint4をfloat4に変換できない。

__vector 型間の明示的な変換は可能だが、同じサイズのベクトル間のみである。 の間でのみ可能である。

long2 a = 8;
short8 b = cast(short8)a;   // OK
short16 c = cast(short16)b; // エラー、サイズが異なるためキャストできない。

__simd 、__simd_sto イントリニクスのユーザーは、各使用時にvoid16から適切な型への明示的なキャストを追加するか、または以下の操作を行わなければならない。 を追加するか、または、値をピー クする必要があるまでvoid16ベクトルを厳密に操作しなければならない。 を厳密に操作しなければならない。

float4 fun1(float4 a, float4 b)
{
    a = cast(float4)__simd(XMM.ADDPD, a, b);
    a = cast(float4)__simd(XMM.ADDSS, a, b);
    return a;
}

float4 fun2(void16 a, void16 b)
{
    a = __simd(XMM.ADDPD, a, b);
    a = __simd(XMM.ADDSS, a, b);
    return cast(float4)a;
}

以前のリリースでは、in をパラメータに使用すると、パラメータが早く下がりすぎた、 エラーメッセージがパラメータを エラーメッセージはパラメーターをconst (-preview=in が使用されている場合はscope const )と表示していた、 エラーメッセージはパラメーターを(または の場合は)と表示し、ヘッダー生成やスタックトレースも表示する。 ヘッダー生成には問題があった。-preview=in で生成されたヘッダーは、そうでないものと異なっていた。 今回のリリースから、in はすべてのメッセージで正しく表示されるようになった。 これはマングリングのアップデートを必要とするため、古いデバッガやツールでは、正しくマングリングを解除できない場合がある。 は、in パラメータを使用する関数を正しくデマングルできないかもしれない。

DdocのMarkdownがデフォルトで有効になった。 サポートされているMarkdownの機能(見出し、強調テキスト、リンクなど)の完全なリストはDdocのドキュメントページで説明されている。

より慎重な人のために、Markdown機能のすべてのインスタンスのリストは、-transition=vmarkdown で記録できる。 この移行で問題が発生した場合、-revert=markdown でMarkdown機能の処理を一時的に無効にし、問題を報告することができる。

この問題を提唱してくれたDavid Gileadiに心から感謝する!

Dは創設以来、in 、ref 、out のパラメータ・ストレージ・クラスをサポートしてきた。 out とref がよく使われている、 しかし、in は、もともと のエイリアスとして意図されたものであったため、通常は取り残されていた。 const scopeのエイリアスとして意図されていたが、const のサポートが導入されると、 のエイリアスになった。 scope のサポートが導入された(DIP1000)。

DMD v2.092.0では、スイッチのない-preview=in の代わりに、const scope 、 const を追加することで修正した。

しかし、これではin の意図する意味を正しく理解できなかった: 入力パラメーターに適用される。 入力パラメータとは、関数が調べるだけのパラメータである、 入力パラメータとは、関数を変更することなく、またその参照を保持することなく、 関数が調べることだけを意図しているパラメータのことである。 これはconst scope でカバーされている。 しかし、入力パラメーターの中にはかなり大きなものがあったり、それをコピーすると副作用があったりする(ポストブリット、コピーコンストラクター)、 したがって、実行時のオーバーヘッドを避けるために、これらのパラメータは参照渡しにすべきである。 そこで新たな問題が発生する:Dはr値の参照渡しをサポートしていない。 したがって、入力パラメーターを受け取るAPIを設計する場合、一般的なやり方は、。 入力パラメーターを受け付けるAPIを設計する場合、in を受け付けるオーバーロードと、in ref を受け付けるオーバーロードの両方を用意するのが一般的だった。 これは1つのパラメータではうまくいくが、組合せの爆発に悩まされる。

このリリースでは、in の意味を見直し、これらの使用例をすべて適切にサポートするようにした。 in パラメータは、最適な場合には参照渡しとなり、r値を受け付けるようになった。 スイッチを使用する場合、in ref パラメーターもエラーとなる。

参照渡しのルールは以下の通りである:

• 型が精巧なコピーや破壊(ポストブリット、コピーコンストラクタ、デストラクタ)を持っている場合、

• コピー不可能な型は、常に参照渡しとなる。
• 参照型(動的配列、関数ポインタ、デリゲート、連想配列、クラス)は、。 は、ref によって渡されることはない。これにより、デリゲートでの共変が可能になる。
• それ以外の場合、型のサイズが必要であれば、参照渡しされる。 現在のところ、マシン語サイズの2倍を超える型は参照渡しとなる、 しかし、これはバックエンドによって制御され、プラットフォームのABIに基づいて変更することができる。

以前は、コンパイラーは以下のコードをすべての -mcpu= 型はOSX 32ビットとすべての64ビット・ターゲットの両方でサポートされている。

__vector(long[4]) x;    // AVXタイプ
x += 1;                 // AVX2演算

このリリースでは、__vector のすべての型と操作が、現在の CPU をチェックするようになった。 をチェックし、サポートが不十分な場合はエラーを出すようになった。

また、__traits(compiles) を使った条件付きコンパイルも可能である。 を使った条件付きコンパイルも可能である。

static if (__traits(compiles, long4))
{
    // `-mcpu=avx`以上の場合にコンパイルされる
}

static if (__traits(compiles, { int4 x; x += 1; }))
{
    // `-mcpu=baseline`以上の場合にコンパイルされる
}

static if (__traits(compiles, { int4 x; x *= 1; }))
{
    // `-mcpu=avx`以上の場合にコンパイルされる
}

static if (__traits(compiles, { int8 x; x += 1; }))
{
    // `-mcpu=avx2`以上の場合にコンパイルされる
}

以下の表は、最低限必要な-mcpu= 。

v2.078以降、いくつかの配列の等式比較(例えば、両方の配列が 動的配列である場合など)は、カスタム.tupleof のない構造体に対して誤って の比較を使用していた。 opEqualsの比較を誤って使用していた。 -preview=fieldwise を強制していた。

union U
{
    string s;
}

void main()
{
    static immutable from = "from", from2 = "from2";
    U[] a = [{ s : from }];
    U[1] b = [{ s : from2[0..4] }];
    assert(a[0] != b[0]);
    assert(a != b);
    assert(a != b[]); // v2.078以前は動作していたが、その後失敗していた、再び動作するようになった
}

新しい関数core.memory.GC.allocatedInCurrentThread() は以下を返す。 core.memory.GC.stats().allocatedInCurrentThreadを返す。 の方が高速である。 これは-profile=gc に使用され、より高速になる。

get-path <compiler> インストール・スクリプトに新しいアクションが追加された。 このアクションにより、コンパイラー・バイナリーの情報を表示できるようになった。 の動作は、以下の追加オプションで変更できる: get-path

• --install ローカルにコンパイラがない場合はインストールする
• --dmd 特定のコンパイラ実行ファイルのパスを返す(DMD類似インターフェース)
• --dub DUB実行ファイルのパスを返す

例:

curl https://dlang.org/install.sh | bash -s get-path --install
/home/user/dlang/dmd-2.093.0/linux/bin64/dmd

~/dlang/install.sh get-path ldc-1.23.0 --install
/home/user/dlang/ldc-1.23.0/bin/ldc2

~/dlang/install.sh get-path --dmd ldc --install
/home/user/dlang/ldc-1.23.0/bin/ldmd2

~/dlang/install.sh get-path --dub ldc --install
/home/user/dlang/ldc-1.23.0/bin/dub

~/dlang/install.sh get-path --dub dub-1.22.0 --install
/home/user/dlang/dub-1.22.0/dub

~/dlang/install.sh get-path --dub ldc,dub-1.22.0 --install
/home/user/dlang/dub-1.22.0/dub

コンパイラーのインストールが見つからず、--install が渡されなかった場合、エラーが発行される。

Linux、OSX、FreeBSDのバイナリリリースが でビルドされるようになった。これは、2.091.0からWindowsリリースのホスト・コンパイラがLDCに変更されたことに伴うものである。 リリースのホスト・コンパイラがLDCに変更された。

LDCでDMDをビルドすると、コンパイラが大幅にスピードアップするはずだ(20～30％)。

この変更には以下の制限がある:

• FreeBSD 32 ビットバイナリのリリースがなくなる (32 ビット LDC ホストコンパイラがなくなる)
• 以前の dmd リリースからコピーされた追加のバイナリツールが含まれなくなった。 (c0de0295e6b1f9a802bb04a97cca9f06c5b0dccd(optlink は含まれている) を参照) これらはまだ https://digitalmars.com/ 経由か、古い dmd リリースから入手可能である。

windows-dmd で x86_omf アーキテクチャをプラットフォーム仕様として使えるようになった。 --arch=x86_omf仕様として使えるようになった。これは現在のところ --arch=x86 と同等である。

バージョン指定のないパッケージ名でコマンドを呼び出した場合、通常は最新バージョンとみなされる、 通常、最新バージョンが想定される。 この動作はdub fetch やdub run では理にかなっている、 を通じてローカルパッケージをクリーンアップする場合、この動作は理にかなっているが、dub remove 、 そのため、以前のバージョンは、複数の バージョンが利用可能な場合、単にエラーになっていた。 このバージョンから、dub remove -n $PKGNAME は、 という名前のパッケージのキャッシュされたバージョンをすべて削除する。 $PKGNAME $PKGNAME@* というパッケージのキャッシュされたバージョンをすべて削除するだけである。

この変更以前は、dub upgrade / 。 で誤ってdub.json を実行すると、 /dub.sdl が存在しない。 dub.selections.json と、場合によっては空の.dub フォルダが残る。 これは修正され、dub upgrade を実行すべきでない場所で実行しても、親切なエラーメッセージが表示されるだけになった。 を実行しても、フレンドリーなエラーメッセージが表示されるだけである。

Gitリポジトリは、依存関係としてdubから直接使用することができる。

dub.json:

{
    "name": "git-dependency",
    "dependencies": {
        "gitcompatibledubpackage": {
            "repository": "git+https://github.com/dlang-community/gitcompatibledubpackage.git",
            "version": "ccb31bf6a655437176ec02e04c2305a8c7c90d67"
        }
    }
}

dub コマンドは、そのバージョン処理に若干のばらつきがあった。 パッケージ名を受け付けるほとんどのコマンド(例: や )は、 のどちらかをサポートしていた。 のどちらかをサポートしていた。 オプション を受け付ける。 後者の形式は現在では非推奨となり、すべてのコマンドが を受け付けるようになった。 がない場合は、依然として「最新バージョン」を意味することに注釈: ( を除く)。 dub fetch dub run package[@version-spec] package --version=<version-spec> package[@<version-spec>] @<package-spec> remove