変更ログ 2.104.0

ある関数が属性推論に失敗すると、その関数のすべての呼び出し元も属性推論に失敗する。 その結果表示されるエラーメッセージは、属性が明示されている最上位の関数のみを指す:

void main() @nogc
{
    fun();
}

auto fun()
{
    funImpl();
}

auto funImpl()
{
    int[] a = [1, 2, 3];
}

app.d(4): Error: @nogc function D main cannot call non-@nogc function app.fun

これでは、@nogc 、fun 属性が推論されなかった根本的な理由が分からず、より良い情報を得るために回避策を使うことになった。 新しいエラーメッセージは、属性の推測に失敗した関数を示す:

app.d(4): Error: @nogc function D main cannot call non-@nogc function app.fun
app.d(7):        which calls app.funImpl
app.d(14):        which wasn't inferred @nogc because of:
app.d(14):        array literal in @nogc function app.funImpl may cause a GC allocation

注釈: これは2.101以降、すでに@safe に実装されていたが、現在は@nogc 、nothrow 、pure に拡張されている。

これはエラーになりやすいため、2.075.0から非推奨となっている:

void main()
{
    foreach (i; 0 .. 8);
    {
        // 上のセミコロンが誤っているため、
        // このブロック文は一度だけ実行される。
        // ループ本体ではない
    }
}

これでエラーになる。

app.d(3): Error: use { } for an empty statement, not ;

-preview=in をデフォルトで有効にするための準備である、 DリンクもC++リンクもない関数でin パラメータを使用することは非推奨である。 ユーザはin のインスタンスをconst またはscope const で置き換えることができる。 v2.101.0の変更履歴を参照のこと。 を参照のこと。

in ref (またはref in) を関数のパラメータに使用することは非推奨となった。 ユーザーは、ref を削除し、-preview=in でコンパイルすることが推奨される、 でコンパイルすることが推奨される。このコンパイルは、パラメータが参照渡しか値渡しかを推論する。 特定のABIを必要とするユーザーは、代わりにscope const ref を使用することが推奨される。 これはauto ref in にも適用されることに注釈:in と-preview=in は等価である、 と等価であるが、後者は関数をテンプレート化する必要はない。

以前は、immutable 、const 、inout 、shared の例外をスローし、非修飾の 節でキャッチすることができた。 をスローし、非修飾のcatch (Exception e) 節でキャッチすることができた。 これでは型安全性が壊れてしまう。 修飾されたオブジェクトをスローすることは非推奨となった。これは これは、catch 節の中で、不変オブジェクトの変異を防ぐのに役立つ。

ランタイムはまた、(例えばスタックトレースを含むように)スローされたオブジェクトを修正する。 トレースを含むように)修正することもある。これは、const またはimmutable オブジェクトに違反する可能性がある。オブジェクトに違反する可能性がある。 オブジェクトをスローすることは、この理由からも非推奨となっている。

UDAに型を記述することはすでに許されていたが、パーサーは直接記述された基本型を拒否し、エイリアスを使用する必要があった。

alias Tint = int;

@Tint void f();

また、テンプレートのインスタンス化において、括弧なしで現れる単純なリテラル(例:foo!"arg" )は、属性として使われるときに括弧を必要とする:

@("my test") unittest
{

}

現在では、テンプレートのインスタンス化foo! の後に現れる引数も、@ 属性の後に現れることができる。

@int void f();

@"my test" unittest
{

}

これまでは、clamp 、渡された型が使えるかどうかをチェックするためにテンプレート制約を使っていた。 が使えるかどうかをチェックしていた。もしそうでない場合、その原因を突き止めるのは非常に面倒だった。

テンプレート制約はオーバーロードの解決には使われないので、制約を静的アサー トに移した。 制約を、表現力豊かなエラーメッセージを持つstatic assertに移した。 メッセージに移される。

Rebindable を含むあらゆる型の値の保存とリバインドに使用できるようになった。 値を含む。 immutable struct

安全性を確保するため、保存された値は参照によってアクセスできない。 を参照することはできない。

これまでサポートされていたすべての型(クラス、インターフェイス、配列)の実装は変更されていない。 および配列)に使用される実装に変更はない。

rdmdはDMDの-shared スイッチを理解し、-lib と同じように、デフォルトの出力ファイル名を適切に設定するようになった(プラットフォームによって、.dll 、.so 、.dylib )。

cSourcePaths 指定されたすべてのディレクトリにある C ソースファイルをコンパイラに渡す。 cImportPaths' に指定されたディレクトリで見つかったすべての C ソースが D コンパイラに渡される。 これにより、D ソースファイルとは別に C ソースを保存していたプロジェクトを D に移植する際の後方互換性が確保される。

2番目のキーワード「cImportPaths」は、Cヘッダーの検索パスを追加する。これらのディレクトリはDコンパイラに渡される。 に渡される。インクルード・パスは現在 Dインポートパスと一緒になっているからである。将来的には、Dコンパイラーに渡されるCの独立した検索パスをサポートするように変更されるかもしれない。

以前のバージョンのdubでは、パッケージは次のような形式で保存されていた: $CACHE_PATH/$PACKAGE_NAME-$PACKAGE_VERSION/$PACKAGE_NAME/ このバージョンからは、以下の形式になる: $CACHE_PATH/$PACKAGE_NAME/$PACKAGE_VERSION/$PACKAGE_NAME.

新しいレベルを導入することで、ユーザーが実際にインストールされているパッケージを素早く一覧できるようになる。 また、頻繁に更新される可能性のあるパッケージが見えにくくなる。 頻繁に更新されるパッケージが見えにくくなる。また、様々なコマンド(例:du)がより便利になる。 様々なコマンド(例えば )をより便利なものにし、パッケージのGC関数への道を開き、手動での閲覧を容易にする。 ブラウジングを容易にする。

さらに重要なのは、将来のバージョンのdubが、パッケージへのパスからバージョンを推測できるようになることだ。 パッケージへのパスからバージョンを推測できるようになる。 を読む(あるいは編集する)必要がなくなる。