このページの英語版を見る

非推奨の機能

時には、機能が単に悪いアイデアであることが明らかになることがある。これらは非推奨機能と呼ばれ、いったん言語から削除するに値すると判断された場合、ユーザーが変更に適応できるよう十分な時間を確保するために、

非推奨の機能
Feature	Spec	Dep	Error	Gone
nothrow関数の契約からのスロー		2.101	2.111
	2.079	2.079	2.086
クラスアロケーターとデアロケーター		2.080	2.087	2.100
異なる列挙型の暗黙の比較	2.075	2.075	2.081
暗黙的な文字列連結	2.072	2.072	2.081
カンマ式の結果を使用する	2.072	2.072	2.079
削除		2.079	2.099	2.109
スコープを型制約として		2.087
虚数および複素型	未来	2.097
128ビット整数型	未来	2.100	2.100
暗黙のcatch文	2.072	2.072	2.081
配列の .sort および .reverse プロパティ	?	2.072		2.075
C言語のスタイルの配列ポインタ	?	2.072	2.082
浮動小数点NCEG演算子	2.079	2.066	2.072	2.080
クリア	2.060	2.066		2.068
浮動小数点数型用のプロパティ	該当なし	2.065	2.067	2.072
T[] を整数型にキャストする	?	2.060		2.061
基本クラス保護	2.058	2.058	2.067	2.072
Windows 3.xおよびWindows 9xのサポート	2.058	該当なし	該当なし	2.058
typedef	2.057	2.057	2.067	2.072
*を使用して配列を間接参照する	?	2.057	2.067	(決して)
不変を不変の別名として使用する	2.057	2.057	2.064	2.066
デフォルトケースのない非最終switch文	2.054	2.054	2.068	(決して)
基底クラスの関数を隠蔽する	2.054	2.054	2.068	(決して)
8進数表記	2.054	2.053	2.067	(決して)
C言語のスタイルの関数ポインタ	?	2.050	2.067	(決して)
インデックス式で長さを使用する	?	2.041		2.061
文字列リテラルのエスケープ	?	2.026	2.061	2.067
揮発性	2.013	2.013	2.067	2.072
HTMLソースファイル	?	2.013	該当なし	2.061
オーバーライドなしでオーバーライドする	?	2.004	2.072	(決して)
整数リテラルに小文字の「l」接尾辞を使用する	?	1.054	0.174	(決して)
関数内部での変数シャドウイング	?	0.161		2.061
虚数リテラルに大文字の「I」接尾辞を付ける	?	0.154	2.061	(決して)
if (v; e)	?	0.149	2.061	2.068
連想配列から項目を削除するdelete	?	0.127	2.061	2.067
.offsetプロパティ	?	0.107	2.061	2.067
.sizeプロパティ	?	0.107	0.107	2.061
.typeinfoプロパティ	?	0.093	2.061	2.067
注釈なしアセンブリブロック			2.100	(決して)
修飾されたオブジェクトのスロー		2.104		(決して)
不変オブジェクト/inoutオブジェクト/共有オブジェクトのキャッチ		2.106		(決して)

仕様: 仕様からの削除
: コンパイラはデフォルトで警告を発し、-de スイッチでエラーを発行し、-d スイッチで警告を抑制できる
エラー: この機能を使用することはエラーである
Gone: その機能は完全に削除された

スロー関数の契約からスローする

xml-ph-0000@deepl.internal 関数の契約から例外をスローすることは許可されていた。

nothrow 関数の契約から例外をスローすることは許可されていた。

float sqrt(float n) nothrow
in
{
    if (n < 0)
        throw new Exception("n must be positive");
}
do
{
    // ...
}

是正措置

nothrow 属性を削除するか、代わりにアサーションを使用して契約を書き直す。

float sqrt(float n) nothrow
in
{
    assert(n >= 0);
}
do
{
    // ...
}

corrective actionassertionassertion

根拠

関数の事前条件と事後条件は暗黙のうちに関数本体の前後に実行されるため、スローを許可すると nothrow 属性の保証が破られることになる。

クラスアロケーターとデアロケーター

Dクラスは、(デ)アロケーション戦略をカスタマイズするメンバーを持つことができる。

class Foo
{
    new(uint size, ...)
    {
        return malloc(size);
    }

    delete(void* obj)
    {
        free(obj);
    }
}

Foo foo = new(...) Foo();
delete foo;

是正措置

(デ)アロケーション戦略をクラスから移動する

class Foo
{
}

T make(T, Args...)(auto ref Args args) if (is(T == Foo))
{
    enum size = __traits(classInstanceSize, T);
    void* mem = malloc(size);
    scope (failure) free(mem);
    return mem !is null ? emplace!T(mem[0..size], args) : null;
}

void dispose(T)(T obj)
{
    auto mem = cast(void*) obj;
    scope (exit) free(mem);
    destroy(obj);
}

Foo foo = make!Foo();
if (foo !is null) dispose(foo);

allocationallocation

根拠

クラスは、自身の(デ)アロケーション戦略を担当すべきではない。

異なる列挙型の暗黙的な比較

異なる列挙型の比較は許可されていた。

enum Status
{
    good,
    bad
}
enum OtherStatus
{
    ok,
    no
}
static assert(Status.good == OtherStatus.ok);

是正措置

無関係な列挙型間の比較は、 std.conv.asOriginalType

import std.conv : asOriginalType;
assert(Foo.x.asOriginalType == Bar.y.asOriginalType);

根拠:

無関係な列挙型同士の比較を禁止することで、コードの正確性が向上する。異なるenum 型の暗黙的な比較は、見つけにくいバグの原因となることがよくある。

xml-ph-0000@deepl.internalxml-ph-0000@deepl.internal

enum { X }
enum { Y }
void main() {
    auto b = X == Y;
    assert(b);
}

暗黙的な文字列連結

隣接する2つの文字列は暗黙的に連結されていた。

string foo = "Hello" "World";

この機能は、複数行にわたる長い文字列の場合に便利であるが、明示的に同じ動作をさせることも可能である。連結演算子(「~」)を使用すればよい。

string foo = "Hello" ~ "World"; // 割り当てを行わない

this featureこの機能

是正措置

暗黙的な文字列連結を明示的なものに置き換える。「~」を使用する。

根拠:

これは言語の非常に初期の機能であり、現在では完全に連結演算子でカバーされている。これは、定数に対してコンパイル時に実行され、メモリ割り当てを発生させない。

。

しかし、暗黙の連結演算子を使用すると、発見が困難なバグが発生する可能性がある。例えば、

hard難しい

string[] names =
[
    "Anna",
    "Michael"
    "Emma",
    "David"
];
// arrの内容は["Anna", "MichaelEmma", "David"]

カンマ式の結果を使用する

カンマ演算子(xml-ph-0000@deepl.internal)は、複数の式を実行し、最後の結果を除いてそれらの結果を破棄する。

カンマ演算子 (,) は、複数の式を実行し、最後の結果を除いたそれらの結果を破棄する。

int a = 1;
int b = 2;
bool ret = a == 2, b == 2; // true

また、カンマ演算子をforループのインクリメント文で使用して、複数の式を許可することも一般的である。

for (; !a.empty && !b.empty; a.popFront, b.popFront)

是正措置

可能であれば、カンマ演算子を2つのステートメントに分割する。そうでない場合は、ラムダを使用する。

可能であれば、カンマ演算子を2つの文に分割する。そうでない場合は、ラムダを使用する。

auto result = foo(), bar();

// 2つの文に分かれる
foo();
auto result = bar();

// またはラムダを使う
auto result = {foo(); return bar();}();

corrective actionラムダ

根拠

カンマ演算子は予期せぬ動作につながる(下記参照)。さらに、一般的に使用されていないため、タプルの実装を妨げる。カンマ演算子の誤用による問題の例:

カンマ演算子は予期せぬ動作につながる(下記参照) さらに、一般的に使用されていないため、タプルの実装を妨げる。カンマ演算子の誤用による問題の例:

writeln( 6, mixin("7,8"), 9 ); // 6, 8, 9

template vec(T...)(T args) { ... }
vec v = (0, 0, 3); // 3、なぜならvecは可変長だからである

int b = 2;
if (a == 1, b == 2) {
    // は必ず届く
}

void foo(int x) {}
foo((++a, b));

synchronized (lockA, lockB) {}
// は現在実装されていないが、カンマ演算子によってコンパイルは可能である

comma operatorカンマ演算子

削除

GCヒープに割り当てられたメモリは、delete で解放できる。

auto a = new Class();
delete a;

xml-ph-0000@deepl.internalxml-ph-0000@deepl.internal

是正措置

使用する

代わりに object.destroy() 代わりにオブジェクトを確定するために使用する。

auto a = new Class();
destroy(a);

destroy は割り当てられたメモリを解放しないことに注意すること。必要であれば、 core.GC.free。

根拠

delete 利用可能なガベージコレクタの型に関する前提条件を設定しており、使用できる実装が制限される。また、ライブラリソリューションに置き換えることもできる。

スコープを型制約として

xml-ph-0000@deepl.internalキーワードをクラス宣言に追加すると、クラスのすべてのインスタンスに xml-ph-0001@deepl.internalストレージを強制的に割り当てることができる。

scope キーワードをクラス宣言に追加すると、そのクラスのすべてのインスタンスにscope ストレージクラスを強制的にアトリビュートすることができる。

scope class C { }          // `scope`型制約である。この`scope`の使い方は非推奨である。

void main()
{
    C c1 = new C();        // エラー: `scope class`への参照は`scope`でなければならない
                           // このエラーは、`class C`の宣言に`scope`属性があり、
                           // `c1`に`scope`ストレージクラス属性がないためである。
                           // 

    scope C c2 = new C();  // インスタンス`c2`には`scope`ストレージクラスが帰属しているのでOKである。
                           // この`scope`の使い方は非推奨ではない。
}

keywordkeyword

修正措置

プログラミング言語Dまたはライブラリには、scopeストレージクラスをアトリビュートするよう型に制約を課すものはない。

根拠:

scope 型制約は、説得力のある使用例のない言語の癖であった。

この非推奨化は、xml-ph-0000@deepl.internal を型制約としてクラス宣言に帰属させる場合の使用法のみに影響することに注意。 xml-ph-0001@deepl.

この廃止は、クラス宣言に起因する型制約としてのscope の使用のみに影響する。変数、関数パラメータなどに起因するストレージクラスとしてのscope は、廃止の対象ではない。

虚数型および複素型

Dは、現在、すべての浮動小数点型の虚数および複素数バージョンをサポートしている。

float a = 2;
ifloat b = 4i;
cfloat c = a + b;
assert(c == 2 + 4i);

complex type複素型

是正措置

ライブラリ型を使用する。 std.complex。

根拠

これらの型は、言語のコアの一部として使用するには特殊すぎる。

これらの型は、言語のコアの一部として使用するには特殊化されすぎている。

128ビット整数型

Dは現在、cent およびucent キーワードを将来の128ビット整数型として予約しているが、これらの使用はコンパイルエラーとなる。

cent a = 18446744073709551616L;
ucent b = 36893488147419103232UL;

keywordkeyword

是正措置

ライブラリ型を使用する。 core.int128。

根拠

これらの型は、言語のコアの一部として使用するには特殊すぎる。

これらの型は、言語のコアの一部として使用するには特殊化されすぎている。

暗黙のcatch文

型を指定せずにcatch を使用すれば、あらゆるものをキャッチできる。

int[] arr = new int[](10);
// これはRangeErrorをスローする
try { arr[42]++; }
catch { writeln("An error was caught and ignored"); }

是正措置

Throwable をキャッチしないか、catch {} を置き換える。catch (Throwable) {}

xml-ph-0000@deepl.internalxml-ph-0000@deepl.internal

int[] arr = new int[](10);
// これはRangeErrorをスローする
try { arr[42]++; }
catch (Throwable) { writeln("An error was caught and ignored"); }

根拠

xml-ph-0000@deepl.internalのキャッチは、言語によって推奨されるべきではない。なぜなら、特定のコア保証が満たされない可能性があるからだ。例えば、スタックがクリーンアップされない可能性やデストラクタが実行されない可能性がある。

Throwable のキャッチは、言語によって推奨されるべきではない。なぜなら、特定のコア保証が満たされない可能性があるからだ。例えば、スタックがクリーンアップされない可能性や、デストラクタが実行されない可能性がある。この変更により、Throwable のキャッチは常にプログラマー側の意識的かつ明白な決定であることが保証される。

.sort および .reverse プロパティ(配列用)

D 配列は、これらの組み込みプロパティを使用して操作することができる。

int[] x = [2, 3, 1];
assert(x.sort == [1, 2, 3]);

是正措置

の汎用関数を使用する。 std.algorithm。

根拠

これらの操作は標準ライブラリで実装する方が望ましい。

C言語のスタイルの配列ポインタ

Cスタイルの配列ポインタはDでも使用できる。

C言語のスタイルの配列ポインタはD言語でも使用できる。

alias float *arrayptr[10][15];

styleスタイル

是正措置

D言語のスタイルの配列ポインタに置き換える。

alias float[15][10]* arrayptr;

根拠:

Dの構文はより簡潔で使いやすい。

浮動小数点NCEG演算子

Dは現在、NCEG浮動小数点演算子 (!<>=、<>、<>=、!>、!>=、!<、!<=、!<>)をサポートしており、NaNを含む比較に使用できる。

是正措置

通常の演算子を使用し、 std.math.traits.isNaN。

根拠:

これらの演算子は、言語のコアの一部として使用するには特殊すぎる。

これらの演算子は、言語のコアの一部として使用するには専門的すぎる。

明確な

オブジェクトのデストラクタを呼び出す。

auto a = new Class();
clear(a);

是正措置

代わりに object.destroy()代わりに使用する。

auto a = new Class();
destroy(a);

corrective actioncorrective action

根拠:

理由は、Uniform Function Call Syntax (UFCS) により、xml-ph-0000@deepl.internal は同じ名前の他のメソッドと混同される可能性があるためである。例えば、xml-ph-0001@

Uniform Function Call Syntax (UFCS) により、clear は同じ名前の他のメソッドと混同される可能性がある。例えば、コンテナの内容を削除する際に使用されるclear メソッドなどである。

浮動小数点型用の.minプロパティ

浮動小数点数型には、最小値にアクセスするための .min プロパティがある。

enum m = real.min;

是正措置

.min_normalに置き換える

enum m = real.min_normal;

根拠

.min_normalという名称の方がより正確である。なぜなら、.minには非正規化浮動小数点値が含まれていないからだ。

T[] を整数型にキャストする

ある時点で、次のようにすることも可能である。

ulong u = cast(ulong)[1,2];

配列の長さを取得する。

是正措置

代わりに、.length プロパティを使用する。

根拠

キャストを使用して配列の長さを取得するのは、混乱を招くだけである。

基本クラスの保護

基本クラスの保護とは、例えば以下のようなものである。

class A : protected B
{
    ...
}

base classベースクラス

是正措置

ベースクラスの前に置かれた保護属性キーワードを削除する。

基本クラスおよび基本インターフェースの前に置かれた保護属性キーワードを削除する。

根拠

Dのモジュールシステムでは、何の役にも立っていないように思えるし、一度も正しく動作したことがない。 @system@system

Windows 3.x と Windows 9x のサポート

Windows 3.x/9x 対応のコードが "phobos" に若干存在する。

是正措置

Windowsをアップグレードするか、別のサポートされているOSに切り替える。

根拠

このような時代遅れでほとんど使用されていないOSをサポートする価値はない。

typedef

typedefは、型に対して厳密な型付けされたエイリアスを構築するために使用できる。

型を強く型付けしたエイリアスを構築するために typedef を使用することができる。

typedef int myint;
static assert(!is(myint == int));

是正措置

typedefの使用を別名またはuseに置き換える。 std.typecons.Typedef。

根拠

typedefは、すべての使用事例をカバーするには柔軟性が十分ではない。これはライブラリソリューションで対応する方が良い。

typedefは、すべての使用事例をカバーするには柔軟性が十分ではない。これはライブラリソリューションで対応する方が望ましい。 typedeftypedef

*を使用して配列をデリファレンスする

配列変数Dをポインタのように参照解除して、最初の要素を取得することができる。

int[] arr = [1, 2, 3];
assert(*arr == 1);

是正措置

最初のメンバーにアクセスするには、インデックス構文を使用する。

int[] arr = [1, 2, 3];
assert(arr[0] == 1);

根拠:

D配列はポインタではない。

不変であり、不変の別名として使用される

不変ストレージクラスおよび型修飾子は、immutableの別名である。

static assert(is(invariant(int) == immutable(int)));

是正措置

不変をストレージクラスまたは型修飾子として使用しているすべての箇所を immutableに置き換える。構造体およびクラス不変の不変()構文は引き続きサポートされる。

根拠

エイリアスは不要である。

デフォルトのケースを含まない最終でないswitch文

switch文はデフォルトケースを省略して宣言でき、コンパイラが自動的にデフォルトケースを追加する。

switch(a)
{
case 1:
    break;
case 2:
    break;
// the compiler adds
// default:
//     throw new SwitchError();
}

non-final switch statement非最終switchステートメント

是正措置

デフォルトのケースを手動で追加する。

switch(a)
{
case 1:
    break;
case 2:
    break;
default:
    assert(0);
}

根拠

デフォルトのケースが欠落しているとバグが隠される可能性があるため、デフォルトのケースを明示することは必須であるべきである。 missing欠落

基本クラス関数の非表示

これは、派生クラスで、基底クラスの関数と同じ引数で呼び出すことができる関数を宣言する際に発生する。その関数をオーバーライドせずに。基底クラスの関数が隠される。

これは、派生クラスで宣言された関数が、その関数をオーバーライドすることなく、基底クラスの関数と同じ引数で呼び出せる場合に発生する。基底クラスの関数は隠される。

class A
{
    void fun(int x) {}
}
class B : A
{
    void fun(long x) {}
}

是正措置

関数をベースクラスに追加するか、エイリアスを使用してベースクラスのオーバーロードを派生クラスに追加する。

class A
{
    void fun(int x) {}
    void fun(long x) {} // これで解決した
}
class B : A
{
    void fun(long x) {}
    alias A.fun fun; // これもそうだ
}

corrective actionベースクラス

根拠

これはすでに実行時に検出されるエラーであり、コンパイル時にも拡張される。 rationale理由

8進数リテラル

8進数リテラルは、8進数でリテラルを入力するために使用できる。

// 非推奨のコード
// auto x = 0123;

是正措置

テンプレートを使用する。 std.conv.octalテンプレートを使用する。

auto x = octal!123;

根拠

先頭ゼロの使用は混乱を招く。0123と123は異なるからだ。 rationale先頭ゼロの使用は混乱を招く

C言語のスタイルの関数ポインタ

Cスタイルの関数ポインタはDでも使用できる。

C言語のスタイルの関数ポインタはD言語で使用できる。

alias void(*fptr)(int, long);

是正措置

D言語のスタイルの関数ポインタに置き換える。

alias void function(int, long) fptr;

corrective action修正措置

根拠:

Dの構文はより簡潔で使いやすい。

インデックス式でlengthを使用する

インデックスまたはスライス式の中で length を使用すると、length はスライスされる配列の長さになるように書き換えられる。

auto a = new int[5];
a = a[0..length-1];

是正措置

length を同等の'$'に置き換える

根拠:

暗黙的に定義された length 変数は既存の宣言を隠蔽し、代替案よりも簡潔ではない。

エスケープ文字列リテラル

エスケープシーケンスを使用して文字を記述するには、エスケープ文字列を使用できる。

// 非推奨のコード
// string x = "hello" ~ \n;

literalリテラル

是正措置

エスケープシーケンスを通常の文字列リテラル内に置く。

string x = "hello\n";

corrective action修正措置

根拠:

エスケープ文字列リテラルは直感的ではなく、不要である。

揮発性

volatileは、コンパイラの最適化を一部無効にするために、ステートメントをマークするのに使用できる。

volatileは、コンパイラの最適化を防ぐために、"文"をマークするために使用できる。

volatile
{
    ... do something involving ghared variables ...
}

volatilevolatile

是正措置

代わりにsynchronized文を使用するようにコードを変更する。

根拠

揮発性文は誤った機能である。

HTMLソースファイル

Dコンパイラは、 <code></code>タグに含まれないものはすべて無視して、htmlファイルを解析することができる。

<html>
<code>
    ... source ...
</code>
</html>

是正措置

コードを通常のソースファイルに抽出する。

根拠

これは、ドキュメント化のために、ddocの導入により置き換えられた

オーバーライドせずにオーバーライドする

仮想関数は、現在、'override' 属性を指定せずにベースクラスの関数をオーバーライドすることができる。

class A
{
    void fun() {}
}
class B : A
{
    // オーバーライドするが、オーバーライドのマークは付けない
    void fun() {}
}

overrideoverride

是正措置

overrideで上書き関数をマークする

class A
{
    void fun() {}
}
class B : A
{
    override void fun() {}
}

根拠

xml-ph-0000@deepl.internal属性を必須にすることで、明示化され、ベースクラスの関数が誤ってオーバーライドされた場合のエラーを検出できる。

override 属性を必須にすることで、明示化され、ベースクラスの関数が誤ってオーバーライドされた場合のエラーを検出できる。

整数リテラルに小文字の「l」接尾辞を使用する

小文字の「l」は、64ビット整数を表す別の接尾辞である。

// 非推奨のコード
// auto x = 123l;

是正措置

大文字の「L」接尾辞を使用する。

auto x = 123L;

根拠

小文字の接尾辞は数字の「1」と混同されやすい。

注釈:

語(ご)彙(い)解析フェーズでは、コンパイラは小文字の接尾辞「l」を認識し、より適切なエラーメッセージを表示することができる。CからDへのコード変換などのユースケースでは、この機能が役立つ。そのため、DMDは「l」接尾辞の解析を継続する。

関数内部での変数シャドウイング

変数シャドウイングとは、内部スコープの変数とそれを囲むスコープの変数とが同じ名前である

void myFun()
{
    int var;
    if (x)
    {
        int var;
        var = 3; // どの変数を指しているのか?
    }
}

variable shadowing変数シャドウイング

是正措置

変数名を変更して、衝突しないようにする。

根拠:

変数のシャドウイングにより、誤った変数が修正されるという見つけにくいバグが発生する可能性がある。 variable shadowing変数のシャドウイング

虚数リテラルに大文字の「I」接尾辞を付ける

I"という接尾辞は、浮動小数点の虚数を表すために使用できる。

// 非推奨のコード
// auto x = 1.234I;

是正措置

小文字の「i」接尾辞を使用する。

auto x = 1.234i;

根拠:

接尾辞「I」は数字の「1」と混同されやすい。

if (v; e)

この構文は、if文の条件で変数を宣言するために使用できる。

if (v; calculateAndReturnPointer()) { ... }

是正措置

自動宣言に置き換える。

if (auto v = calculateAndReturnPointer()) { ... }

根拠

自動の方が構文が明確である。

連想配列から項目を削除する delete

deleteを使用して、連想配列から項目を削除することができます。

deleteを使用すると、連想配列から項目を削除することができる。

int[int] aa = [1 : 2];
delete aa[1];
assert(1 !in aa);

是正措置

代わりに.removeを使用すること。

代わりに .remove を使用する。

int[int] aa = [1 : 2];
aa.remove(1);
assert(1 !in aa);

根拠:

削除構文はわかりにくく、通常の削除構文と競合する。

.offsetプロパティ

. offsetプロパティは、メンバーのオフセット情報を取得するために使用できる。

.offsetプロパティは、メンバーのオフセット情報を取得するために使用できる。

struct S { int a, b; }
static assert(S.b.offset == 4);

是正措置

代わりに.offsetofを使用する

struct S { int a, b; }
static assert(S.b.offsetof == 4);

offsetofoffsetof

根拠:

.offsetの構文は.offsetofに置き換えられた

。sizeプロパティ

.sizeプロパティは、型サイズ情報を取得するために使用できる

struct S { int a, b; }
static assert(S.size == 8);

sizesize

是正措置

代わりに.sizeofを使用する

代わりに .sizeof を使用する

struct S { int a, b; }
static assert(S.sizeof == 8);

sizeofsizeof

根拠

. size 構文は .sizeof に置き換えられた

.size構文は.sizeofに置き換えられた

。typeinfoプロパティ

.typeinfoプロパティは、関連するTypeInfoクラスを取得するために使用できる。

T.typeinfo

是正措置

代わりにtypeid()を使用する

typeid(T)

根拠

根拠:

理由は

.typeinfo構文はtypeid()に取って代わられた

注釈なしasmブロック

ブロックは関数注釈に影響を与えない。

asm ブロックは関数注釈に影響を与えない。

void foo() @safe
{
    asm { noop; }
}

是正措置

xml-ph-0000@deepl.internalブロックに注釈を付ける代わりに

asm ブロックに注釈を付ける代わりに

void foo() @safe
{
    asm @trusted { noop; }
}

xml-ph-0000@deepl.internalxml-ph-0000@deepl.internal

根拠:

ブロックは、スローする可能性がある、安全でない不純なコードを含んでいる、またはGCインターフェースを呼び出している可能性がある。

asm ブロックは、スローする可能性がある、安全でない、"pureでない"コードを含んでいる、またはGCインターフェースを呼び出している可能性がある。

修飾されたオブジェクトのスロー

以前は、immutable 、const 、inout 、またはshared 例外がスローされ、修飾されていないcatch (Exception e) 節でキャッチされることがあった。これは型安全性を損なう。修飾されたオブジェクトのスローは現在非推奨となっている。これにより、catch 節における不変オブジェクトの変異の可能性を

また、スローされたオブジェクトは実行時に変更される(例えば、スタックトレースを含めるなど)ため、const またはimmutable オブジェクトの違反となる可能性がある。この理由からも、修飾オブジェクトのスローは非推奨となっている。

不変/inout/共有オブジェクトのキャッチ

例外をimmutable 、inout 、またはshared としてキャッチすることは安全ではない。これは、例外が他の変更可能または共有でない参照を通じてアクセス可能である可能性があるためである。

auto e = new Exception("first");
try {
        throw e;
} catch(immutable Exception ie) { // unsafe
        e.msg = "second";
        assert(ie.msg == "first"); // would fail
}

DEEPL APIにより翻訳、ところどころ修正。
このページの最新版(英語)
このページの原文(英語)
翻訳時のdmdのバージョン: 2.109.1
ドキュメントのdmdのバージョン: 2.109.1
翻訳日付 :2025-01-01 14:19:05+09:00
HTML生成日時: 2025-01-09 08:12:17+09:00
編集者: dokutoku