構造型のoutパラメータを割り当てる必要はありません

コードレビュー中に関数の行を誤ってコメントアウトすると、コードに奇妙な動作が見られます。再現は非常に困難でしたが、ここでは同様の例を示します。

私はこのテストクラスを持っています：

public class Test
{
    public void GetOut(out EmailAddress email)
    {
        try
        {
            Foo(email);
        }
        catch
        {
        }
    }

    public void Foo(EmailAddress email)
    {
    }
}

GetOut通常はエラーをスローする電子メールへの割り当てはありません。

コントロールが現在のメソッドを離れる前に、出力パラメーター 'email'を割り当てる必要があります

ただし、EmailAddressが別のアセンブリの構造体にある場合、エラーは発生せず、すべてが正常にコンパイルされます。

public struct EmailAddress
{
    #region Constructors

    public EmailAddress(string email)
        : this(email, string.Empty)
    {
    }

    public EmailAddress(string email, string name)
    {
        this.Email = email;
        this.Name = name;
    }

    #endregion

    #region Properties

    public string Email { get; private set; }
    public string Name { get; private set; }

    #endregion
}

コンパイラが電子メールの割り当てを強制しないのはなぜですか？構造体が別のアセンブリで作成されている場合、このコードはコンパイルされますが、構造体が既存のアセンブリで定義されている場合はコンパイルされないのはなぜですか？

TLDR：これは、長期にわたる既知のバグです。私は2010年にそれについて最初に書きました：

https://blogs.msdn.microsoft.com/ericlippert/2010/01/18/a-definite-assignment-anomaly/

それは無害であり、安全に無視でき、ややあいまいなバグを発見したことを祝福します。

コンパイラーはEmail確実に割り当てなければならないことを強制しないのはなぜですか？

ああ、そういう風に。後で説明するように、変数が確実に割り当てられていることをどの条件が意味するかについては、誤った考えがあります。

構造体が別のアセンブリで作成されている場合、このコードはコンパイルされますが、構造体が既存のアセンブリで定義されている場合はコンパイルされないのはなぜですか？

それがバグの核心です。このバグは、C＃コンパイラが構造体の明確な割り当てチェックを行う方法と、コンパイラがライブラリからメタデータをロードする方法の共通部分の結果です。

このことを考慮：

struct Foo 
{ 
  public int x; 
  public int y; 
}
// Yes, public fields are bad, but this is just 
// to illustrate the situation.
void M(out Foo f)
{

さて、この時点で私たちは何を知っていますか？ fはタイプの変数のエイリアスですFoo。そのため、ストレージはすでに割り当てられており、少なくともストレージアロケータから出た状態にあります。呼び出し元によって変数に配置された値があった場合、その値はそこにあります。

何が必要ですか？私たちはf、コントロールがM正常に終了するすべてのポイントで確実に割り当てられることを要求します。したがって、次のようなものが期待されます。

void M(out Foo f)
{
  f = new Foo();
}

どのセットf.xとf.yそのデフォルト値に。しかし、これはどうですか？

void M(out Foo f)
{
  f = new Foo();
  f.x = 123;
  f.y = 456;
}

それも大丈夫です。しかし、ここにキッカーがあります。なぜデフォルト値を割り当てて、すぐにそれらを吹き飛ばす必要があるのでしょうか。 C＃の明確な割り当てチェッカーは、すべてのフィールドが割り当てられているかどうかを確認します。これは合法です：

void M(out Foo f)
{
  f.x = 123;
  f.y = 456;
}

そしてなぜそれが合法ではないのですか？値型です。 fは変数であり、既に typeの有効な値が含まれているFooので、フィールドを設定するだけで完了です。

正しい。それで、バグは何ですか？

あなたが発見したバグは次のとおりです： コスト削減のため、C＃コンパイラーは参照ライブラリーにある構造体のプライベートフィールドのメタデータをロードしません。そのメタデータは巨大になる可能性があり、毎回それをすべてメモリにロードすることはほとんど成功しないため、コンパイラの速度が低下します。

これで、発見したバグの原因を推測できるはずです。コンパイラーは、outパラメーターが確実に割り当てられているかどうかを確認するときに、既知のフィールドの数を、初期化された明確なフィールドの数と比較し、プライベートフィールドのメタデータが読み込まれなかったため、ゼロのパブリックフィールドのみを認識します。。コンパイラーは、「ゼロフィールドが必要で、ゼロフィールドが初期化されているので問題ない」と結論付けています。

私が言ったように、このバグは10年以上前からあり、あなたのような人々は時々それを再発見して報告します。それは無害であり、修正する利点はほとんどありませんが、パフォーマンスコストが大きいため、修正される可能性はほとんどありません。

そしてもちろん、このバグは、プロジェクトのソースコードにある構造体のプライベートフィールドを再現しません。明らかに、コンパイラはすでにプライベートフィールドに関する情報を持っているためです。

それはバグのように見えますが、それはある程度の意味があります。

「欠落エラー」は、クラスライブラリを使用している場合にのみ表示されます。また、クラスライブラリがVB.Netなどの別の.net言語で記述されている可能性もあります。「明確な割り当ての追跡」はC＃の機能であり、フレームワークの機能ではありません。

だから全体としてはバグだとは思いませんが、これについての正式な声明については知りません。