変更ログ 2.092.0

これらのスイッチはすでに何もしておらず、しばらく前から非推奨となっていた。 コンパイラーはもうこれらを認識しない。

GNU ABIタグは、GCC 5.1のC++11で追加された機能である。 Dが標準C++ライブラリを完全にサポートできるようにするためである、 DMDは、core.attribute で宣言され、gnuAbiTag でパブリックにエイリアスされた特別なUDA を認識するようになった。object (でパブリックにエイリアスされている)。 ABIタグは低レベルの機能であり、ほとんどのユーザーは操作する必要がない、 しかし、ABIタグを必要とするC++ライブラリとバインドするために使用することができる。 特に std::string 特に、C++11以上をターゲットにしている場合は、バインドする必要がある(DMDスイッチ-extern-std={c++11,c++14,c++17} )。

以下のように使用できる:

extern(C++):
@gnuAbiTag("tagOnStruct")
struct MyStruct {}
@gnuAbiTag("Multiple", "Tags", "On", "Function")
MyStruct func();

一度に1つのシンボルに存在できるのは、gnuAbiTag のみである。 配列エントリーの順序は問題ではない(出力時にソートされる)。 UDAが効果を発揮するのは、-extern-std=c++11 またはそれ以上がコンパイラに渡された場合だけである。 がコンパイラに渡された場合のみ効果がある。デフォルト(-extern-std=c++98 )はUDAを無視する。 このUDAはextern(C++) シンボルにのみ適用でき、名前空間には適用できない。

モジュールのコンストラクタとデストラクタは(共有であるかどうかにかかわらず)、 とは異なるリンケージでマークされる可能性がある。 extern(D)と異なるリンケージでマークされる可能性がある。 このようなマングリングは単純で予測可能なので、同じ種類の このような揶揄は単純で予測可能なので、同じ種類のコンストラクタ/デストラクタが同じような条件で宣言された場合、衝突の可能性はごくわずかである。 このようなマングリングは単純に予測できるため、同じ種類のコンストラクタ/デストラクタが同じような条件で宣言された場合、衝突の可能性は非常に小さかった。 例えば、モジュールa の3番目のモジュールコンストラクタが479行目にあり、モジュール の3番目のモジュールコンストラクタが479行目にあった場合である。 の3番目のモジュールコンストラクタが479行目にあり、b の3番目のモジュールコンストラクタも479行目にあったとする、 の3番目のモジュールコンストラクタが479行目にあった場合、これらは同じマングリングを持つことになる。

このようなバグが実際に発生する可能性は低い、 影響を受けたシンボルは非推奨メッセージが表示されるようになった。

DIP25はv2.067.0から利用できるようになった、 当初は独自のスイッチとして、最近では-preview=dip25 。 この機能は現在完全に機能し、例えばDIP1000によって構築されている。

このリリースから、-preview=dip25 がコンパイラに渡されたときにエラーが発生するコードは、 がなくても非推奨メッセージが表示されるようになった。 が渡されたときにエラーを発生させるコードも、-preview=dip25 なしで非推奨メッセージを発生させるようになる。 スイッチの動作に変更はない(エラーは発生する)。

DIP25は、@safe コードが破壊されたオブジェクトを参照できないようにすることを目的としている。 実際には、ref をパラメータに返す"関数"や"メソッド"は、コンパイラが示唆するように、メソッドやパラメータを と修飾する必要があるかもしれない。 をパラメータに返す関数やメソッドは、コンパイラが示唆するように、メソッドやパラメータをreturn として修飾する必要があるかもしれない。

struct Foo
{
    int x;
    // `this.x`を返すと、パラメータ`this`への参照がエスケープされる、おそらく`return`でアノテーションする
    ref int method() /* return */ { return this.x; }
}
// `v`を返すと、パラメータ`v`への参照がエスケープされる、おそらく`return`でアノテーションする
ref int identity(/* return */ ref int v) { return v; }

どちらの場合も、return のアノテーションをアンコメントすることで、コンパイラをなだめることができる。 DIP25の完全な説明はここにある。

ポインターの所有権/借用(別名OB)システムは、再参照されたポインターが有効なメモリー・オブジェクトを指していることを保証することができる。 参照されたポインタが有効なメモリ・オブジェクトを指していることを保証する。

プロトタイプOBシステムの範囲

これはDに適応したOBシステムのプロトタイプである。 のみであり、動的配列、クラス参照、参照、集合体のポインタ・フィールドは対象としていない。 には対応していない。このようなサポートを追加すると複雑さが増す、 が、本質を変えるものではないので、後回しにする。 RAIIオブジェクトはそれ自身のメモリを安全に管理できるため、OBの対象にはならない。 OBではカバーされない。ポインタがGCを使用してメモリを割り当てるか、他の記憶域割り当て手段を使用してメモリを割り当てるかは、OBには関係ない。 これらは区別されず、同じように扱われる。 同じように扱われる。

このシステムは、@live 属性でアノテーションされた関数でのみ有効である。 このシステムは、純粋にOBルール違反のチェックとして、意味処理が行われた後に適用される。 OBルール違反のチェックとして意味処理後に適用される。新しい構文は追加されない。新しい構文が追加されることはない。 生成されるコードに変更は加えられない。 @live "関数"が"関数 "以外の関数を呼び出す場合、呼び出された関数は "関数 "以外の関数を呼び出すことが期待される。 が@live 以外の関数を呼び出す場合、呼び出された関数は と互換性のあるインターフェイスを持つことが期待される。 @live 互換のインターフェイスを提示することが期待される。 非@live 関数が@live 関数を呼び出す場合、渡される引数は の規約に従っていることが期待される。 @live の規約に従うことが期待される。

OBシステムはエラーとして検出する:

• 無効な状態のポインターを参照する。
• 変更可能なメモリー・オブジェクトへの複数のアクティブ・ポインタ。

null ポインタや、おそらくは null ポインタの可能性もある。これは実行不可能である。 というのも、null 以外のポインタとして型をアノテートする方法が現在存在しないからである。

コアOB原則

OBデザインは以下の原則に則っている:

各メモリ・オブジェクトには、それに対する1つの変異ポインタか、複数の変異しない(読み取り専用の)ポインタが存在する。 または複数の変異しない(読み取り専用)ポインタが存在する。

デザイン

単一の変異ポインターは、メモリ・オブジェクトの「オーナー」と呼ばれる。 このポインターは、メモリ・オブジェクトと、そこからアクセス可能なすべてのメモリ・オブジェクト(つまりメモリ・オブジェクト・グラフ)を推移的に所有する。 つまりメモリー・オブジェクト・グラフ)を所有する。そのメモリー・オブジェクトへの唯一のポインターである そのメモリー・オブジェクトへの唯一のポインターであるため、そのメモリーを安全に管理することができる。 メモリを安全に管理することができる。 他のポインター(変異しているかどうかにかかわらず)を引きずり出すことなく、安全にメモリーを管理することができる。 の下敷きにすることなく、安全にメモリーを管理することができる。

メモリ・オブジェクト・グラフへの複数の読み取り専用ポインタがある場合、メモリ・オブジェクト・グラフから安全に読み取ることができる、 メモリ・オブジェクト・グラフへの複数の読み取り専用ポインタがあれば、メモリ・オブジェクト・グラフが足元で変更されることを気にすることなく、安全に読み取ることができる。 オブジェクト・グラフが足元で変更されることを気にすることなく、そこから安全に読み出すことができる。

設計の残りの部分は、ポインタがどのようにオーナーになるか、読み取り専用ポインタ、無効なポインタ、そしてコアOB原則がどのように変更されるかに関係している、 残りの設計は、ポインタがどのように所有者になるか、読み取り専用ポインタになるか、無効ポインタになるか、そしてコアOB原則がどのように維持されるかについてである。 を常に維持する方法である。

追跡ポインタ

追跡されるポインターは、@live 関数内で宣言されたものだけである。 this関数のパラメータまたはローカル変数として宣言されたものである。他の 他の関数からの変数は、@live であっても追跡されない。 他の関数との相互作用の解析は、その関数のシグネチャではなく、完全にその関数のシグネチャに依存するからである。 他の関数との相互作用の分析は、その内部ではなく、関数のシグネチャに依存するからである。 const であるパラメータは追跡されない。

ポインターの状態

各ポインターは以下のいずれかの状態にある:

未定義

Ownerポインタが別のOwnerポインタに代入されると、前者は未定義状態になる。 は未定義の状態になる。

借用ポインタはscope 属性を持っていなければならない。 へのポインタでなければならない。

ライフタイム

借用ポインタ値または読み取り専用ポインタ値のライフタイムは、それが最初に読み取られたとき(初期化されたときや値が割り当てられたときではない)に開始し、次の時点で終了する。 ポインタ値の寿命は、最初に読み込まれたとき(初期化されたときや値が割り当てられたときではない)に始まり、その値の最後の読み取りで終わる。 で終了する。

これは、Non-Lexical Lifetimesとしても知られている。

ポインターの状態遷移

ポインタの状態は、ポインタに対してこれらの操作が行われたときに変化する:

• ポインタのストレージが確保される(スタック上のローカル変数など)、 ポインタが未定義の状態になる

技術的にはconst scope と定義されているが、in クラスが実装されたことはなかった。 実装が完了したことで、in は純粋に入力関数のパラメータとして選択されるようになった。 になるはずである。

-preview=in がなければ、この2つの宣言は等価である:

void fun(in int x);
void fun(const int x);

-preview=in では、これら2つの宣言は等価である:

void fun(in int x);
void fun(scope const int x);

printfはC99仕様7.19.6.1、scanfは7.19.6.2に従う。

printfに関しては、互換性に関して厳密ではなく寛大な見方をする。 例えば、符号なし値は符号付き指定子でフォーマットできる。

scanfの場合、互換性については厳格な見方をする。

診断された非互換性は以下の通りである:

1. 引数のズレを引き起こす互換性のないサイズ
2. ポインタでない引数をデフレンシングする
3. 引数の数が足りない。
4. 構造体引数
5. 配列とスライス引数
6. s 、ポインタ以外の引数を指定する。
7. 非標準フォーマット
8. C99での未定義の動作:.

C標準では、余分な引数は無視される。

引数や書式文字列を修正しようとはしない。

非標準のprintf/scanfフォーマットを使うための簡単な回避策は以下の通りである:

printf("%k\n", value);  // エラー: 非標準フォーマットk

const format = "%k\n";
printf(format.ptr, value);  // エラーなし

検出されたエラーのほとんどは移植性の問題である。例えば、次のようなものだ、

string s;
printf("%.*s\n", s.length, s.ptr);
printf("%d\n", s.sizeof);
ulong u;
scanf("%lld%*c\n", &u);

と置き換えるべきである:

string s;
printf("%.*s\n", cast(int) s.length, s.ptr);
printf("%zd\n", s.sizeof);
ulong u;
scanf("%llu%*c\n", &u);

printf-like関数とscanf-like関数は、printf-like関数の場合は、scanf-like関数の場合は を先頭に付けることで検出される。 printf-like関数とscanf-like関数は、printf-like関数の場合はpragma(printf) 、scanf-like関数の場合はpragma(scanf) を前につけることによって検出される。

プラグマに加えて プラグマに加えて、関数は以下の特徴に従わなければならない:

1. extern (C) またはextern (C++)
2. としてフォーマット・パラメーターを宣言する。const(char)*
3. v以外の関数の場合、formatパラメータを... の直前に置く、 または、va_list (これは "v"の最後のパラメータである。 printf scanfの最後のパラメータである)。

これは、フォーマット文字列引数と引数リストの自動検出を可能にする。

v "フォーマット文字列のチェックはまだ実装されていない。

環境変数SOURCE_DATE_EPOCH は 再現可能なビルドに使用される。 これはUNIXタイムスタンプ(1970-01-01 00:00:00からの秒数)である、 である。 DMDはこれを正しく認識し、__DATE__ 、 __TIME__と__TIMESTAMP__ トークンを設定する。

TypeInfo_Class.isBaseOf 引数とレシーバが等しいか が等しいか、引数で表されるクラスがレシーバーで表されるクラスを継承している場合に真を返す。 を継承している場合に真を返す。これは と呼ばれる。 と呼ばれる。 これは、オーバーロードするクラスの混乱を避けるためと、D 。 引数は または . isBaseOfisAssignableFromopAssign TypeInfo_Interface.isBaseOf TypeInfo_ClassTypeInfo_Interface

class ClassA {}
class ClassB : ClassA {}

auto a = new ClassA(), b = new ClassB();

assert(typeid(a).isBaseOf(typeid(a)));
assert(typeid(a).isBaseOf(typeid(b)));
assert(!typeid(b).isBaseOf(typeid(a)));

pageSize には、システムページのサイズがバイト単位で格納される。

import core.memory : pageSize;
ubyte[] buffer = new ubyte[pageSize];

minimumPageSize には、システムページの最小サイズがバイト単位で含まれている。

これはコンパイル時、プラットフォーム固有の値である。この値はコンパイル時のものであり、プラットフォーム固有の値である。 なぜなら、この値を変更できる可能性があるからである。可能な限り 実行時に初期化されるpageSize 。

最小サイズは、コンテキストがコンパイル時に既知の値を必要とする場合に便利である、 静的配列のサイズのようにubyte[minimumPageSize] buffer 。

import core.memory : minimumPageSize;
ubyte[minimumPageSize] buffer;

ISO8601週暦から、DateやDateTimeで使用されるグレゴリオ暦への変換が可能になった。 グレゴリオ暦に変換できるようになった。

日付は、ISO 週カレンダーの年、週番号、曜日から構成される。 と曜日から構成される。Date.fromISOWeek(2020, 11, DayOfWeek.mon) 。 Date(2020, 3, 9).

グレゴリオ暦の年とISO週暦の年は必ずしも同じではない。 グレゴリオ暦の年とISO週暦の年は必ずしも同じではないので、ISO週暦の年を取得するための新しい.isoWeekYear " プロパティが用意されている。 Date を取得するための新しいプロパティが用意されている。両者を頻繁に変換する場合は 週番号と年の両方を一度に計算するには、.isoWeekAndYear を使用することを検討する。 ステップで計算できる。

std.xml モジュールは非推奨となった。まだ 代わりにUndeaDを使うことができる。 xmlファイルのパースには、dubパッケージである dxmlを使うことを推奨する。

これらは2.076.1から非推奨となり、現在は削除されている。 代わりにstd.digest またはそのサブモジュールをインポートする。

さらに、std.digest.digest の非推奨サイクルが開始された。 され、このモジュールは2.101で削除される。

ほとんどのPosixファイルシステムでは、隠しディレクトリはピリオドで始まる。 .dub.デフォルトでは、dubは隠しファイル(例:.swap.file.d )は無視するが、隠しディレクトリは無視しない。 は無視される。オペレーティングシステムによっては、dubがコンパイル時にインクルードしようとする隠しディレクトリを作成するものもある。 がコンパイルのためにインクルードしようとする。このリリースでは を適切に無視するようになった。 recipeファイルで特に指定されていない限り、適切に無視するようになった。

これはディレクトリ名のみを使用し、ファイルの属性をチェックしないことに注釈:。 属性はチェックしない。

Dub lintは--report-file引数で呼び出せるようになった: dub lint --report-file report.json