変更ログ 2.095.0

集約宣言にプライベート・メソッドとパブリック・メソッドが同じオーバーロード・セットに含まれている場合、別のモジュールからプライベート・メソッドを呼び出すことができる。 同じオーバーロード・セットにプライベート・メソッドとパブリック・メソッドが含まれている場合、別のモジュールからプライベート・メソッドを呼び出すことができる。

例:

==============================
module foo;

struct Foo
{
  import std : writeln;

  private int _x;

  private ref int x() return
  {
    writeln("ref int");
    return _x;
  }

  int x() const
  {
    writeln("int");
    return _x;
  }
}
============================

---
module main;


void main()
{
  import std : writeln;
  import foo : Foo;


  auto f = Foo();
  f.x = 3;              // プライベートのメソッドの呼び出しOK
  writeln(f);
}
===========================

非推奨を扱う際によくある問題は、ライブラリ・コード内で非推奨がトリガーされることだ、 例えば、deprecated alias this 、またはフック(opApply 、レンジ・プリミティブ...)がある。 が"phobos"内部に深くネストされた関数から呼び出される。

このような場合、インスタンス化がどこから来ているのかを見つけるのは非常に面倒である。 今回のリリースから、非推奨化がテンプレート内部でトリガーされた場合、コンパイラーはテンプレートのインスタンス化のトレースを表示するようになった。 はテンプレートのインスタンス化のトレースを表示する。 同じ制限が適用され(6フレーム、再帰テンプレートは圧縮される)、それを解除するために-v を使って解除できる。

以下の機能/バグ修正/改善が に実装された:

• 列挙型 "はマクロで生成されなくなり、enum class 。 -extern-std= 、c++11以降のC++標準セットが使用される。
• 前方参照宣言が適切にインデントされるようになった。
• デフォルト関数のパラメータが適切に出力されるようになった。
• タプルメンバー/パラメーター/変数が個々の変数として出力される として発行されるようになった。
• インターフェイスが基底クラスとして出力されるようになった。
• 集約メンバは適切な保護レベルで出力される。
• 集約内の保護された列挙型が再び発行される。
• プライベートメンバメソッドが発行されなくなった
• 共用体のデフォルトコンストラクタが自動生成されなくなった。
• externブロックの中にネストされた宣言を無視しなくなった、 例extern(D) extern(C++) void foo() {}
• 不透明な列挙型によるセグメンテーション・フォールトが発生しなくなり、C++ 11 用に適切にエクスポートされるようになった。
• -extern-std=c++98 でコンパイルする際、C++11 の構成要素が回避されるようになった。
• typeof(null) 型を使用してもアサーションに失敗しなくなった。
• 浮動小数点リテラルのベース型がヘッダーに反映されるようになった。
• NaN math.h から / を使用して が発行される。NANINFINITY Infinity
• 最終クラスはfinal
• immutable は変更可能" ではなく として出力される。const
• テンプレート内の識別子チェーンは完全に出力される。
• vtableの適切なレイアウトは、 でない仮想関数のプレースホルダを非表示にすることで確保される。 extern(C|C++) でない仮想関数のプレースホルダを非表示にすることで、適切な vtable レイアウトが確保される。
• クラス・メンバー/メソッドのconst の欠落が修正された。
• テンプレート化されたクラス宣言が出力されるようになった
• extern(C|C++) でないマニフェスト定数は出力されなくなった。

注釈: ヘッダー・ジェネレーターはまだ実験的なものである。 バグがあればバグトラッカーに送ってほしい。

以前は、モジュール内で同一の関数が複数定義されていても、それを認識することはできなかった。 を認識していなかった。これは、バイナリがシンボルの複数の定義を含むことができないため、問題があった。 バイナリはシンボルの複数の定義を含むことができないため、コンパイラのバックエンドによっては未定義の挙動を引き起こす の挙動を引き起こす。

DMDは、1つのモジュール内で競合する実装がある場合、エラーメッセージを出すようになった。 がある場合、エラーメッセージを表示するようになった:

void foo() {}
void foo() {} // エラー

最大でも1つの定義がある限り、複数の宣言が許される:

void bar(int);
void bar(int) { }
void bar(int);

DMDはオーバーロードをサポートしないスキームのマングリングに対して非推奨を発表する。 (extern(C|Windows|System)):

extern(C):
void foo(int) { }
void foo(double) { } // 非推奨

この非推奨は2.105ではエラーとなる。

この未使用のリンケージはv2.084.0、非推奨となり、現在は削除されている。

コンパイラーは-extern-std= のサポート標準として c++20 を受け付けるようになった。 現在のところ、これは__traits(getTargetInfo, "cppStd") の値を変更するだけである、 の値を変更するだけだが、将来的に新しい型が追加される可能性がある。

-extern-std= のデフォルト設定が c++11 に更新された。

extern(C++) C++98コンパイラでコンパイルされたコードとのリンクは保証されなくなった。 とのリンクは保証されなくなった。さらに-HC によって生成された C++ ヘッダーは、C++11 以降でのみ使用可能な構文を使用する。

古いC++コンパイラーとの互換性が必要な場合は、コマンドラインで -extern-std=c++98 を渡す必要がある。

Liskovにあるように、in の契約は、それらが現れるメソッドに置かれた条件のみを緩めることができる。 現在は、in の契約とin の契約を自動的に "オーリング"することで、これを実現している。 と自動的に "連結"され、必然的に親メソッドよりも緩い "契約"が作成される。

しかし、これはこのコード・パッシングのような奇妙な振る舞いにつながる:

class A
{
    void foo(int i) in (i > 0) { }
}
class B : A
{
    void foo(int i) in (i < 0) { }
}
unittest { (new B).foo(5); }

それは、B.foo のin 契約が暗黙のうちに super.in() || i < 0 、つまり、 になっているからである。i > 0 || i < 0

-preview=inclusiveincontracts では、このコードはAssertError で失敗する。 以前の動作に戻すには、in (i > 0 || i < 0) ; つまり、親のin "契約"を明示的に子の"契約"に含めるのである。

Objective-Cプロトコル][objc_protocol]を宣言できるようになった。Dでは、これは はinterface キーワードを使って宣言される。

Objective-Cのプロトコルの動作に合わせるために、次のような変更が加えられた。 が加えられた:

• インターフェイスの中でオプショナル・メソッドを宣言することができる。これは

• インターフェイスの中にstatic 。このメソッドは

例:

import core.attribute : optional, selector;
import std.stdio : writeln;

struct objc_selector;
alias SEL = objc_selector*;

extern (C) SEL sel_registerName(in char* str);

extern (Objective-C)
extern class NSObject
{
    static NSObject alloc() @selector("alloc");
    NSObject init() @selector("init");
}

extern (Objective-C)
interface Foo
{
    bool respondsToSelector(SEL sel) @selector("respondsToSelector:");
    void foo() @selector("foo");

    // これはオプションのメソッド
    @optional void bar() @selector("bar");
}

extern (Objective-C)
class Bar : NSObject, Foo
{
    override static Bar alloc() @selector("alloc");
    override Bar init() @selector("init");

    bool respondsToSelector(SEL sel) @selector("respondsToSelector:");

    void foo() @selector("foo")
    {
        writeln("foo");
    }
}

void main()
{
    Foo f = Bar.alloc.init;

    // インスタンス`f`がメソッド`bar`を実装しているかどうかを実行時にチェックする
    if (f.respondsToSelector(sel_registerName("bar")))
        f.bar();
    else
        f.foo();
}

[objc_protocol][https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithProtocols/WorkingwithProtocols.html] 。

以前はtrue またはfalse リテラルのみが許可されていた(仕様では整数が使えることになっていたが、そうではなかった)。

現在、pragma は、bool に変換可能な任意のコンパイル時式を受け取ることができる。この式は、ターゲット関数が実際に使用されるときにのみ評価される。

例えば、以下のコードでは、3つの関数はすべてインライン化されている:

pragma(inline, canInline("func1"))
void func1() {}

void func2()
{
    pragma(inline, canInline(__traits(identifier, __traits(parent, {}))));
}

pragma(inline, canInline("func3") || true)
void func3() {}

int canInline(string fname)
{
    switch (fname)
    {
        case "func1":
        case "func2":
            return 1;
        default:
            return 0;
    }
}

void main()
{
    func1();
    func2();
    func3();
}

この新しいトレイトは、シンボルが存在する名前空間を表す文字列のタプルを返す。 これは、リフレクションで使用するために、与えられたシンボルがどの名前空間に存在するかを決定することを可能にし、以下に示すように、extern(C++) 宣言で直接使用することができる。

extern(C++, "ns")
struct Foo {}
static assert(__traits(getCppNamespaces, Foo)[0] == "ns");
struct Bar {}
static assert(!__traits(getCppNamespaces, Foo).length);
extern(C++, __traits(getCppNamespaces, Foo)) struct Baz {}
static assert(__traits(getCppNamespaces, Foo) ==  __traits(getCppNamespaces, Baz));

core.thread.osthread にあるこれらの変数は、誤って公開されてしまった。 直接アクセスすべきでないため、privateになった。 GCシグナルを設定するには、代わりにthread_setGCSignals 。

フラグdoCount をYes.doCount に設定することにより、この関数は名前付きタプルを返す。 このタプルはフィールドdata とcount を含む。 フィールドdata はTarget 型であり、元の関数の結果を含む。 フィールドcount はsize_t 型であり、消費された文字数が格納されている。 それ以外は、この関数は元の振る舞いを維持している。 例:":

import std.typecons : Flag, Yes, No;

string s1 = "123";
auto a1 = parse!(int, string, Yes.doCount)(s1);
assert(a1.data == 123 && a1.count == 3);

のgetdelim とgetline に対する一般に利用可能なextern(C) バインディングは非推奨である。 std.stdio のバインディングは廃止された。まだ必要なコードは、代わりにdruntimeの のシンボルをインポートできる。 core.sys.posix.stdio シンボルをインポートできる。

JSONValue.get で、格納されている または を任意の符号付き整数または符号なし整数に変換できるようになった。 に変換できるようになった。変換は で実行される。 で実行され、整数オーバーフローの場合は をスローする; uinteger integer std.conv.to ConvException

auto json = parseJSON(`{"a": 123}`);
writeln(json["a"].get!ubyte);

このリリース以前は、dubはいくつかのコマンドに対してのみ正確なバージョンを取得することができた (describe,generate,fetch, etc...)。すべてのコマンドがバージョン指定を受け付けるようになった、 dub.json /dub.sdl にあるようなものだ:

dub fetch 'foo@>0.2.0' dub describe foo@'>=0.3.0 <1.0.0'

なお、describe のようなコマンドでは、ネットワークからのフェッチはできない。

デフォルトでは、DubはsourcePaths の下にあるすべてのファイルを使用する。 しかし、複数のターゲットを扱うときによくあるパターンとして コンフィギュレーションを使用することである。これらのターゲットが実行可能ファイルの場合、ユーザーは他のコンフィギュレーションからメインファイルを追加しなければならない、 ユーザは、他のコンフィギュレーションからメイン・ファイルをリストに追加するか、メイン・ファイルを実行可能なディレクトリに保存することを余儀なくされる。 excludedSourceFiles リストに追加するか、メインをsourcePathsの外側の別のディレクトリに保存しなければならない。 の外側の別のディレクトリに格納する必要がある。

このワークフローを単純化するために、DubはmainSourceFileにリストされたファイルを除外する。 にリストされたファイルを除外するようになった。これが望ましくない場合は、ファイルを手動で sourceFiles 。

buildOptionsにbetterCが指定された場合、visualdプロジェクトファイルもbetterCを使うように設定される。 も betterC を使うように設定される。

ユーザー定義のunittest設定がないプロジェクトの場合、dub test 、メインファイルが自動的に生成される。 このメイン・ファイルはキャッシュされるようになり、ファイルを変更することなく次回以降に実行する際に再生成されることはない。

例::

{
    "name": "example",
    "dependencies": {
        "vibe-d": { "version" : "~>0.9.2", "dflags" : ["-preview=in"] }
    }
}

この例では、-preview=in は、vibe-d とその依存関係すべてに適用される。 build settingsフィールドはすべて解析される、 しかし、コンパイル時に考慮されるのは、今のところdflags だけである。

DFLAGS および 、デフォルトで環境変数としてエクスポートされなくなった。 環境変数としてエクスポートされなくなった。 LFLAGS

それでも以前の動作が必要な場合は、dub.jsonの$DFLAGS 、$LFLAGS 。 例えば preGenerateCommands : ["DFLAGS=$DFLAGS env | grep DFLAGS"]

は、環境変数DFLAGSに使用されているすべてのdflagsを出力する。

dubは環境変数DC を尊重するようになった。つまり、DC=ldc2 dub build はdub build --compiler=ldc2 のように動作する。 両方が指定された場合でも、--compiler スイッチが優先される。 DUBが再帰的に自分自身を呼び出す場合、例えばpreGenerateCommands 、 DC これは、ネストされたDUBの呼び出しが同じコンパイラを使用することを意味する。

dubはシングルモードでテストコマンドを実行できるようになった:dub test --single yoursinglefile.d

.dub/obj を$DUB_TARGET_PATH/obj に移動させることで、同じプロジェクトで異なる設定(例えばクロス・コンパイル)の共存と並行コンパイルが可能になる。

listコマンドに、名前とバージョン指定によるオプションのフィルタリング機能を追加した:

dub list foo dub list foo@'>=0.1.0 <1.0.0'

.netrcファイルで定義された基本認証情報 で定義された基本認証情報が考慮されるようになった。 リポジトリに接続する際に考慮されるようになった。