変更履歴 2.085.0

このリリース以前は、Objective-Cのクラスを表すためにDインターフェイスが使用されていた。 今回、Objective-Cクラスの適切なサポートが追加され、Objective-Cクラスを表すためにDクラスが使用できるようになった。 が使用できるようになった。Objective-Cクラスを表すにはD クラスを使用することが望ましい。

このリリースでは、Objective-CのサブクラスとメソッドをDで実装するためのサポートも追加されている。 メソッドの実装がサポートされた。

Objective-Cでの動作に合わせるために、さらにいくつかの変更が加えられている:

• static そして、 のメソッドが仮想化された。 。 メソッドをサブクラスでオーバーライドすることはできない。final final final
• static メソッドはサブクラスでオーバーライドできる

例:":

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

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

    int bar(int a) @selector("bar:")
    {
        return a;
    }
}

void main()
{
    auto foo = Foo.alloc.init;
    scope (exit) foo.release();

    assert(foo.bar(3) == 3);
}

Objective-Cクラスでインスタンス変数を宣言できるようになった。

Objective-Cのインスタンス変数は壊れにくい。つまり つまり、サブクラスが再コンパイルや再リンクをしなくても、基底クラスが変更(インスタンス変数の追加や削除)できるということだ。 は再コンパイルや再リンクを必要としない。この機能のおかげで、サブクラスへのバインディングを作成するときに インスタンス変数を宣言する必要はない。

例:

extern (Objective-C)
class NSObject {}

extern (Objective-C)
class Foo : NSObject
{
    int bar;

    static Foo alloc() @selector("alloc");
    Foo init() @selector("init");
    void release() @selector("release");

    void getBar() @selector("getBar")
    {
        return bar;
    }
}

void main()
{
    auto foo = Foo.alloc.init;
    scope (exit) foo.release();
    foo.bar = 3;

    assert(foo.getBar() == 3);
}

Objective-Cのメソッドを実装し、ベース・クラスのメソッドをスーパー・コールすることが可能になった。 をスーパー・コールできるようになった。

例:

extern (Objective-C)
class NSObject
{
    void release() @selector("release");
}

extern (Objective-C)
class Foo : NSObject
{
    int foo() @selector("foo")
    {
        return 3;
    }
}

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

    override int foo() @selector("foo")
    {
        return super.foo() + 1;
    }
}

void main()
{
    auto bar = Bar.alloc.init;
    scope (exit) bar.release();

    assert(bar.foo() == 4);
}

このリリース以前は、Objective-CクラスをDインターフェイスとして表現する必要があった。 をDインターフェイスとして表現する必要があった。現在ではObjective-Cクラスのサポートが実装されており、代わりに 代わりにclass キーワードを使用する必要がある。

この非推奨の理由は、将来的にextern (Objective-C) を将来Objective-Cのプロトコルを表現するために再利用できるようにするためである。

非推奨:

extern (Objective-C) interface NSObject {} // 非推奨

と置き換える:

extern (Objective-C) class NSObject {}

このリリースで、DMD はコンテキストを考慮したアサーション・エラー・メッセージの生成をサポー トする。 を生成できるようになった。 例えば、現在以下のファイルがある:

void main()
{
    int a, b = 2;
    assert(a == b);
}

をコンパイルして実行すると、このようなエラーになる:

> dmd -run main.d
core.exception.AssertError@main.d(4): Assertion failure
––––––––––
??:? _d_assertp [0x1c4eae48]
onlineapp.d:4 _Dmain [0x1c4ead85]

しかし、新しい実験的なコンパイラー・スイッチ-checkaction=context :

> dmd -checkaction=context -run main.d
core.exception.AssertError@main.d(4): 0 != 2
––––––––––
??:? _d_assert_msg [0x4a3f9cf0]
??:? _Dmain [0x4a3f8fc4]

新しいスイッチはすでにさまざまなアサーション・メッセージをサポートしている:

string dlang = "d2";
assert(dlang != dlang); // エラー: "d2" == "d2"

struct S { int s; }
assert(S(0) == S(1)); // エラー: "S(0) !is S(1)"

int a = 1, b = 2;
assert(a > b); // エラー: 1 <= 2

また、エラーメッセージが生成できない場合は、次のように表示される。 assert のテキストを表示するようになった。例えば、次のような複雑な場合である。 アサート式:

void main()
{
    int a, b = 2;
    assert(a && (a == b));
}

-checkaction=context 、コンパイルして実行すると、次のようになる:

> dmd -checkaction=context -run main.d
core.exception.AssertError@main.d(4): assert(a && (a == b)) failed
––––––––––
??:? _d_assert_msg [0xb7e5fdfc]
??:? _Dmain [0xb7e5fd40]

コンテキストを意識したアサーション・エラー・メッセージのためのこのスイッチは、まだ実験的なものである。 であり、フィードバックを歓迎する。

DMDの以前のバージョンでは、文書化されていないconst-castの相互作用があった。 cast() cast(const) これらのキャストはcast(immutable) のように表現される。 cast(const(typeof(expr))) exprしたがって、expr がStruct 型であった場合、これらのキャストはその構成体を呼び出す可能性があった、 したがって、Struct(expr) が 型であった場合、これらのキャストは のコンストラクタを呼び出す可能性がある。

しかし危険なのは、最初のフィールドを。 をalias this 、alias this を介した暗黙の変換は、潜在的に暗黙の構造体コンストラクタを満たすことになる。 暗黙的な構造体のコンストラクタを満たす可能性があり、他のフィールドはinit に設定されたままになる。 cast()のデータ破損につながる。

つまり、cast() s からS(s) へ、S(s.implicitCast) 。

これはもはや起こりえない。 cast(), cast(const) and cast(immutable) will no longer generate an implicit constructor call. S() への暗黙のコンストラクタ呼び出しは、明示的にcast(S) を使用した場合にのみ発生する。

新しいCLIオプション-verrors=context を使うと、dmdはエラーメッセージに問題のある行を直接表示するようになる。 test.d というプログラムを考えてみよう:

void foo()
{
    a = 1;
}

-verrors=context で実行する:

> dmd -verrors=context test.d
test.d(4): Error: undefined identifier a
    a = 1;
    ^

コンパイラーは、構造体オブジェクト全体にわたって memcmp() を使用した構造体の等式テストのコードを生成することがあった。これは次のことを想定していた:

1. アライメントホールが0で埋められている。
2. 浮動小数点のNaN値がなかった。 たとえビットパターンが一致していても

仕様では、比較はメンバ単位で行われることになっている。 これにより、実装はこれに沿ったものになる。

平等式

これは、以前の誤った動作に依存していた既存のコードを壊す可能性がある。 そのようなコードを修正するには、以下のいずれかを使用する:

1. opEquals() 演算子オーバーロードを定義して、希望する動作を実現する。
2. is は構造体オブジェクトのビット比較を行うので、== の代わりにis を使用する。

この新しい動作は、-preview=fieldwise コンパイラー・スイッチで有効になる。この新しい動作は、 コンパイラー・スイッチで有効になる。 最終的にはデフォルトの動作になるだろう。

このリリースで、DMDコンパイラーはOSX用の32ビット・アプリケーションのビルドを公式にサポートしなくなった。 OSX用32ビット・アプリケーションのビルドは公式にサポートされなくなる。レガシーな目的であれば、古いリリース を使うことができる。

Motivation: 最新のmacOSリリースMojaveは、32ビットアプリケーションの実行をサポートするOSXの最後のバージョンである。 最後のバージョンである。D開発チームは D開発チームは、活動的で重要なプラットフォームに労力を集中し、インフラを構築／テストしたいと考えている。

D言語の機能を追加したり削除したりするコマンドラインスイッチは、通常、アドホックに追加されてきた。 しかし、時が経つにつれて、これは次第に大きくなっていった:

• -dip25
• -dip1000
• -dip1000
• -dip1008

さらに、並行して-transition 、以下のDMDが導入された。 の例は、現時点でDMDがサポートしているトランジショナル機能のサブセットに過ぎない:

dmd -transition=3449 -transition=10378 -transition=14246 -transition=14888 -transition=16997

これらのトランジションにも別名があるが、ユーザーにとってはまだ明確ではない。 (a)実験的な機能なのか、それとも近々行われる変更なのか、 (b)今後の変更に関する警告やヘルプ、(c)今のところ変更に対処したくないユーザーのための変更の差し戻し、なのか。 なのか、(c)今のところブレークチェンジに対処したくないユーザーのための変更の差し戻しなのか、ユーザーにはまだわからない。

このリリースで、DMDは-preview コマンドラインスイッチを獲得した。これは、今後の機能や潜在的に壊れそうな変更をテストするために使用できる。 例えば、このリリースでは、今後の機能のリストは次のようになっている:

• -preview=dip25:DIP25(密閉型リファレンス)の実装
• -preview=dip1000:DIP1000(スコープドポインタ)を実装している。
• -preview=dip1008:DIP1008(@nogc Throwables) を実装する。
• -preview=markdown:DdocのMarkdown置換を有効にする。
• -preview=fixAliasThis:alias this 、DMDが上位スコープを検索する前にまずこのスコープをチェックするようになった。
• -preview=intpromote:単項演算子+ 、- 、~ の積分昇格を有効にする。
• -preview=dtorfields:部分的に構築されたオブジェクトのフィールドを破壊できるようにする潜在的に壊れやすい修正を有効にする。

新しい機能を追加することは、既存のコード・ベースを破壊する可能性がある。最初にそれらを -preview スイッチの後ろに置くことで、ユーザーは自分のペースでそれに適応する機会を十分に得ることができる。

したがって、エンドユーザーにとって、新しい-preview のインターフェースは、未来を垣間見ることができる。 いつものように、-preview のすべての機能に対するフィードバックやバグ報告は大歓迎であり、奨励される、 潜在的な問題や不具合を早期に発見できるように。

-preview 、デフォルトで有効になる機能は必ずある、 すべてのContinuous Integrationsをパスし、最も人気のある50のDパッケージのテストスイートをパスしなければならない。 そして、Bugzillaで既知の重大な問題がないことだ。

しかし、DMDの動作が以前のバージョンからわずかに逸脱する可能性があるため、D開発チームによって、問題が発生した場合にユーザーが新機能を簡単にオプトアウトできるようにする、-revert スイッチが導入されることがある。 現在のところ、DMDはこれらの差し戻しを提供している:

• -revert=dip25:DIP25の変更を元に戻す
• -revert=import:単相の名前検索に戻す

-transition 新機能への移行(または重要なバグの修正)は些細なことではないことが非常に多い。 -transition のオプションは情報提供のみであり、今後の変更の問題点を把握したり、変更のデバッグを支援したりすることを目的としている。 例えば、DMDは現在以下のトランジションをサポートしている:

• -transition=field:オブジェクト(instance) : objectオブジェクトのインスタンスを構成する全ての変更可能なフィールド(field) : fieldフィールドをリストアップする。
• -transition=checkimports:10378の異常に関する非推奨メッセージを発する
• -transition=complex:複雑な型や虚数型のすべての用法について、非推奨メッセージを発する。
• -transition=tls:スレッドローカルストレージに入るすべての変数をリストアップする
• -transition=vmarkdown:DdocのMarkdown置換のインスタンスをリストアップする

-transition コマンドラインスイッチは、変更の重要性が(実際のコードへの影響と比較して)十分に高いと考えられる場合、実際の非推奨になるかもしれない、 しかし、それらは開発者がある移行によって影響を受ける場所についての情報としてのみ意図されている。

これらの情報はリリースのたびに継続的に更新されるため、3つのコマンドラインスイッチはすべて、現在利用可能なすべてのオプションを一覧表示する、h 、help または? オプションのヘルプページをサポートしている:

> dmd -preview=help
...
> dmd -revert=help
...
> dmd -transition=help
...

重要:すべての古いコマンドラインスイッチは機能し続け、非推奨になることはない。 しかし、これらはドキュメントから削除された。 -preview -revert を使うことが推奨される。

C++11では、文字型のマングリングが変更された。 D言語のデフォルトの動作は、1回のリリース移行期間の後、これに準拠することになる。 リリースの移行期間を経て、これに準拠するようになる。新しいスイッチ -extern-std={c++98,c++11} が追加された。 互換性が設定されるバージョンを制御するための新しいスイッチ -extern-std={c++98,c++11} が追加された。 このスイッチは、__traits(getTargetInfo, "cppStd") の値を設定する。 __cplusplus の値に設定する。

特に注目すべきは、Windowsにおけるwcharとwchar_tの新しい違いである。 の違いである。これは、Windows APIを呼び出す際に WindowsのAPIを呼び出す際に、wchar*とwchar_t*のコードをインターフェイスすると、コンパイル・エラーとして現れる。 キャストすれば問題は解決する。

今後、Windows API関数と連動する際には、wcharやwchar_tの代わりにWCHARを使うことを推奨する。 の代わりにWCHARを使うことを推奨する。(WCHARはマイクロソフトの Windowsの16ビット文字型である)。

C++型の等価性

c++98の動作:

c++11:

名前の揶揄:

C++98の動作:

c++11:

現在のGCプロファイリング情報へのアクセスを許可する。 詳細は core.memory.GC.ProfileStatsを参照のこと。

C++ のグローバル new/delete 演算子とのインターフェイスを公開するcore.stdcpp.new_ を追加した。 これにより、DプログラムはC++ヒープから便利にアロケートできるようになり、言語間でメモリを共有する場合に便利である。

セット内のCPU数を返すcore.sys.linux.sched.CPU_COUNT を追加した。

cpu が set のメンバーであるかどうかをテストするcore.sys.linux.sched.CPU_ISSET を追加した。

emplace は、 と対をなすものであるため、druntime (core/lifetime.d) に移動し、浅いランタイム・ライブラリ・スタックを使うプロジェクトからアクセスできるようにした。 と は、関連する低レベルの構築マシンであり、 に属している。 destroymove moveEmplace forward core.lifetime

GCのデフォルトのクリーンアップ方法は、実行終了前に無条件に コレクションを実行することである。 オブジェクトを最終化する。 を保持する。これは最悪の選択肢を組み合わせたものである: かなりの遅延が発生する可能性がある。 を保証しない。

クリーンアップの動作は、GC設定のDRTオプションで設定できるようになった。 オプションで設定できるようになった、 例えば、コマンドラインで--DRT-gcopt=cleanup:none 。 を渡すことで設定できる。3つのオプションが用意されている:

• collect: コレクションを実行する(後方互換性のためのデフォルト)。
• none: 何もしない。
• finalize: すべてのライブオブジェクトを無条件にファイナライズする。

いつものように、設定をアプリケーションに埋め込むこともできる。 rt_optionsを再定義することでアプリケーションに設定を埋め込むこともできる。

extern(C) __gshared string[] rt_options = [ "gcopt=cleanup:none" ];

正確なヒープ・スキャンは、GCコンフィギュレーションのDRTオプションで有効にできるようになった。 GCコンフィギュレーションに 例えば、コマンドラインで--DRT-gcopt=gc:precise 。 を渡すか、rt_options を再定義する。詳しくは ドキュメントを参照のこと。 を参照のこと。

の仕様が若干変更された。 core.memory.GC.reallocの仕様が若干変更された:

• GC.realloc 失敗すると を返すようになった。(以前は元のポインターを返していたが 成功時にも返される可能性があるため、失敗を示すのに適していない。これは 拡大が要求された場合、メモリを上書きすることになる)。null
• GC.free と同様に、呼び出し元は、 に渡されたメモリへのライブポインタが他にないことを確認しなければならない。 GC.realloc (以前は、新しいサイズ0 を渡すときにのみ必要だった)。
• その結果、GCは即座にメモリを解放することができる(以前の実装では 以前の実装では、縮小時に4kBより大きなオブジェクトに対してこれを行った)。
• 既存のブロックの属性ビットは、それが再利用される場合にのみ設定される(以前の実装では は小さなブロックを再利用する場合、ビットをセットしなかった)。

この実装では、ポインタが実際に割り当てられたGCメモリへのベース・ポインタであることを適切に検証するようになった。 GCメモリへのベース・ポインタであることを適切に検証するようになった(他のポインタを渡すと、GCが即座にクラッシュしたり、GCを破壊する可能性があった)。

GCレジストリが実装された。 ガベージ・コレクタの実装を追加することができる。 バイナリにリンクするだけでガベージコレクタ実装を追加できる。 詳しくは ドキュメント を参照のこと。

C++std::allocator<T> クラスを公開するcore.stdcpp.allocator を追加した。 これは、STLコンテナ型を割り当てるために必要な基盤である。

D ランタイムのほとんどの構造体(core.* とrt.* モジュール)において、単一のchar/wchar または固定長の配列であるフィールドが、すべての 1 ビットではなく、すべての 0 ビットに初期化されるようになった。これにより初期化が簡素化され、構造体全体がゼロ初期化される際にinitデータを格納する必要がなくなった。影響を受けるほとんどの構造体は、C APIとの相互運用性のために使用される。

dub fetch <package>@<version> のショートカットである。 : dub fetch <package> --version=<version>

> dub fetch gitcompatibledubpackage@1.0.4
Fetching gitcompatibledubpackage 1.0.4...

属性extraDependencyFiles を使って、ファイルのリストを指定することができる。 を指定することができる。

既存のファイルシステムサプライヤーが使用可能になっている。 これは、特定のディレクトリから"[パッケージ名]-[バージョン].zip "という形式のファイルを検索する。 "[パッケージ名]-[バージョン].zip "という形式のファイルを検索する。

"例:dub fetch mypackage --registry=file:///etc/dub/packages/

DUBは、dub.json またはdub.sdl の新しいエントリーをサポートするようになった。 DUBとパッケージがサポートするコンパイラのバージョンを制限するための新しいエントリーをサポートするようになった。

dub.json:

{
    "toolchainRequirements": {
        "dub": "~>1.10",
        "frontend": ">=2.068 <2.083"
    }
}

dub.sdl:

toolchainRequirements dub="~>1.10" frontend=">=2.068|<2.083"

toolchainRequirements :

• dub
• フロントエンド
• dmd
• ldc
• gdc

それぞれに バージョン指定を含むことができる、 ここで、DMDのようなバージョンは、SemVerのバージョンに加えてサポートされている。コンパイラの場合 コンパイラーでは、バージョン指定の代わりにキーワードno を使用することもできる。 を使うこともできる。

シナリオ例:
DUB>=1.12を必要とし、LDC>=1.10でのみビルドされるパッケージ:

dub.json:

{
    "toolchainRequirements": {
        "dub": ">=1.12",
        "dmd": "no",
        "gdc": "no",
        "ldc": ">=1.10"
    }
}

dub.sdl:

toolchainRequirements dub=">=1.12" dmd="no" gdc="no" ldc=">=1.10"