Roslynはコードのコンパイルに失敗しました

プロジェクトをVS2013からVS2015に移行した後、プロジェクトはビルドされなくなりました。次のLINQステートメントでコンパイルエラーが発生します。

static void Main(string[] args)
{
    decimal a, b;
    IEnumerable<dynamic> array = new string[] { "10", "20", "30" };
    var result = (from v in array
                  where decimal.TryParse(v, out a) && decimal.TryParse("15", out b) && a <= b // Error here
                  orderby decimal.Parse(v)
                  select v).ToArray();
}

コンパイラはエラーを返します：

エラーCS0165未割り当てのローカル変数 'b'の使用

この問題の原因は何ですか？コンパイラの設定で修正できますか？

この問題の原因は何ですか？

コンパイラのバグのようです。少なくともそうでした。が、decimal.TryParse(v, out a)そしてdecimal.TryParse(v, out b)式が動的に評価され、私は期待コンパイラはまだ理解して、それが到達した時点でa <= b、両方aとb確実に割り当てられています。動的型付けで思い付く奇妙さがあるとしても、a <= b両方のTryParse呼び出しを評価した後でしか評価しないと思います。

しかし、それはオペレータと変換トリッキーを通じて、それを表現するために持っている完全に実現可能だということが判明したA && B && C評価AとCではなくB、あなたしている狡猾なのに十分な場合-を。Neal Gafterの独創的な例については、Roslynバグレポートを参照してください。

その処理をdynamicさらに困難にする-オペランドが動的である場合に関連するセマンティクスを説明することは困難です。これは、オーバーロードの解決を実行するために、オペランドを評価して関連する型を見つける必要があるため、直観に反する場合があります。ただし、ここでもニールは、コンパイラエラーが必要であることを示す例を考え出しました。これはバグではなく、バグ修正です。それを証明するためのニールへの莫大な賞賛。

コンパイラの設定で修正できますか？

いいえ。ただし、エラーを回避する代替手段があります。

最初に、動的になるのを止めることができます。文字列のみを使用することがわかっている場合は、範囲変数のタイプを使用IEnumerable<string> または指定できます（つまり）。それが私の好みのオプションです。vstringfrom string v in array

あなたがいる場合、本当にダイナミックにそれを維持する必要があり、ちょうど与えるbと開始する値：

decimal a, b = 0m;

これは害を及ぼすことはありません- 実際の動的評価では何もおかしくないことがわかっているためb、使用する前に値を割り当ててしまい、初期値は無関係になります。

さらに、括弧の追加も機能するようです：

where decimal.TryParse(v, out a) && (decimal.TryParse("15", out b) && a <= b)

これにより、さまざまなオーバーロード解決がトリガーされるポイントが変わり、たまたまコンパイラーが幸せになります。

まだ残っている問題が1つあります。2つのオペランドを持つ「通常の」実装で演算子が使用されている&&場合にのみ適用されることを明記するには、演算子による明確な割り当てに関する仕様のルールを明確にする必要があります。これが次のECMA標準で修正されることを確認してみます。&&bool

これは、Roslynコンパイラのバグ、または少なくとも回帰のようです。それを追跡するために、次のバグが報告されています。

https://github.com/dotnet/roslyn/issues/4509

それまでの間、Jonの優れた答えにはいくつかの回避策があります。

バグレポートで一生懸命勉強したので、自分で説明しようと思います。

想像Tへの暗黙的なキャストを持ついくつかのユーザー定義型であるboolとのことで交互falseとtrue、始まりますfalse。コンパイラーが知る限り、dynamic最初の引数の最初の引数は&&その型に評価される可能性があるため、悲観的である必要があります。

次に、コードをコンパイルすると、これが発生する可能性があります。

• 動的バインダーが最初のを評価するとき、&&次のことを行います。
  • 最初の引数を評価する
  • これはT-暗黙的ににキャストされboolます。
  • あ、falseそうなので、2番目の引数を評価する必要はありません。
  • &&評価の結果を最初の引数にします。（いいえ、false何らかの理由で、ではありません。）
• 動的バインダーが2番目のを評価するとき、&&次のことを行います。
  • 最初の引数を評価します。
  • これはT-暗黙的ににキャストされboolます。
  • おお、それtrueはなので、2番目の引数を評価します。
  • ...がらくた、b割り当てられていません。

つまり、変数が「確実に割り当てられている」か「確実に割り当てられていない」かだけでなく、「falseステートメントの後に確実に割り当てられている」か「確実に割り当てられている」かを示す特別な「明確な割り当て」ルールがあります。trueステートメントの後に割り当てられます。」

これらは存在し&&、and ||（およびand !および??and ?:）を処理するときに、コンパイラーは、変数が複雑なブール式の特定のブランチに割り当てられるかどうかを調べることができます。

ただし、これらは、式のタイプがブール値のままである間のみ機能します。式の一部がdynamic（または非ブール型の静的型）である場合、式が次のtrueいずれであるかを確実に言うことができなくなります。false次に実行boolする分岐を決定するためにキャストするときに、考えが変わった可能性があります。

更新：これは解決され、文書化されました：

以前のコンパイラーによって動的式に実装された明確な割り当て規則により、コードが確実に割り当てられない変数が読み取られる可能性があるコードのケースが許可されていました。この1つのレポートについては、https：//github.com/dotnet/roslyn/issues/4509を参照してください。

...

この可能性があるため、valに初期値がない場合、コンパイラーはこのプログラムのコンパイルを許可してはなりません。以前のバージョンのコンパイラ（VS2015より前）では、valに初期値がない場合でも、このプログラムをコンパイルできました。Roslynは、初期化されていない可能性のある変数を読み取るこの試みを診断します。

これはバグではありません。このフォームの動的式がこのようなout変数を未割り当てのままにする方法の例については、https：//github.com/dotnet/roslyn/issues/4509#issuecomment-130872713を参照してください。