C＃がcaseブロックにローカルスコープを持たないのはなぜですか？

私はこのコードを書いていました：

private static Expression<Func<Binding, bool>> ToExpression(BindingCriterion criterion)
{
    switch (criterion.ChangeAction)
    {
        case BindingType.Inherited:
            var action = (byte)ChangeAction.Inherit;
            return (x => x.Action == action);
        case BindingType.ExplicitValue:
            var action = (byte)ChangeAction.SetValue;
            return (x => x.Action == action);
        default:
            // TODO: Localize errors
            throw new InvalidOperationException("Invalid criterion.");
    }
}

そして、コンパイルエラーを見つけて驚いた：

「action」という名前のローカル変数がこのスコープで既に定義されています

解決するのは非常に簡単な問題でした。2番目の要素を取り除くだけでvarうまくいきました。

明らかに宣言された変数caseのブロックは親のスコープを持っているswitchが、私はこれが理由として興味があります。C＃は、実行が（それは他のケースを落下することはできませんことを考える必要があり break、return、throw、またはgoto caseすべてのの終わりに文caseブロック）、1内部変数宣言ができるようになるということは非常に奇妙に思えるcase他に使用されるか、または変数と競合することがcase。言い換えると、変数はcase、実行できない場合でもステートメントを通り抜けるように見えます。C＃は、混乱したり簡単に悪用されたりする他の言語の一部の構造を禁止することにより、読みやすさを高めるために多大な苦労をしています。しかし、これは混乱を引き起こすだけのように思えます。以下のシナリオを検討してください。

1. これに変更する場合：

   case BindingType.Inherited:
       var action = (byte)ChangeAction.Inherit;
       return (x => x.Action == action);
   case BindingType.ExplicitValue:
       return (x => x.Action == action);

   「未割り当てのローカル変数「アクション」の使用」を取得します。C＃の他のすべてのコンストラクトでvar action = ...は、変数を初期化すると考えられるため、これは混乱を招きますが、ここでは単純に宣言しています。

2. 私がこのようなケースを交換した場合：

   case BindingType.ExplicitValue:
       action = (byte)ChangeAction.SetValue;
       return (x => x.Action == action);
   case BindingType.Inherited:
       var action = (byte)ChangeAction.Inherit;
       return (x => x.Action == action);

   「宣言される前にローカル変数 'action'を使用できません」と表示されます。したがって、ここではケースブロックの順序は完全には明らかではない方法で重要に見えます-通常、私は望む順序でこれらを書くことができますが、使用されるvar最初のブロックに現れる必要があるため、ブロックactionを微調整caseする必要がありますそれに応じて。

3. これに変更する場合：

   case BindingType.Inherited:
       var action = (byte)ChangeAction.Inherit;
       return (x => x.Action == action);
   case BindingType.ExplicitValue:
       action = (byte)ChangeAction.SetValue;
       goto case BindingType.Inherited;

   エラーは発生しませんが、ある意味では、変数は宣言される前に値が割り当てられているように見えます。
   _{（あなたが実際にこれをやりたいと思う時間は考えられませんが、goto case今日まで存在することすら知りませんでした）}

私の質問は、なぜC＃のデザイナーがcaseブロックに独自のローカルスコープを与えなかったのかということです。これには歴史的または技術的な理由がありますか？

正当な理由は、他のすべてのケースで、「通常の」ローカル変数のスコープがブレース（）で区切られたブロックだからだと思います{}。正常ではないローカル変数は、forループ変数やで宣言された変数のように、ステートメント（通常はブロック）の前の特別な構造に現れますusing。

もう1つの例外はLINQクエリ式のローカル変数ですが、これらは通常のローカル変数宣言とはまったく異なるため、そこで混乱する可能性はないと思います。

参考のため、規則は§3.7C＃仕様の範囲にあります。

• local-variable-declarationで宣言されたローカル変数のスコープは、宣言が発生するブロックです。

• ステートメントのswitch-blockで宣言されたローカル変数のスコープはswitch-blockです。switch

• ステートメントのfor-initializerで宣言されたローカル変数のスコープforは、for-initializer、for-condition、for-iterator、およびステートメントに含まれるステートメントですfor。

• foreach-statement、using-statement、lock-statementまたはquery-expressionの一部として宣言された変数のスコープは、指定されたコンストラクトの展開によって決定されます。

（switchブロックが明示的に言及されている理由は完全には分かりませんが、他の言及されたすべての構成とは異なり、ローカル変数の宣言のための特別な構文はありません。）

しかし、そうです。で行をラップすることで、どこでもローカルスコープを作成できます{}

switch (criterion.ChangeAction)
{
  case BindingType.Inherited:
    {
      var action = (byte)ChangeAction.Inherit;
      return (x => x.Action == action);
    }
  case BindingType.ExplicitValue:
    {
      var action = (byte)ChangeAction.SetValue;
      return (x => x.Action == action);
    }
  default:
    // TODO: Localize errors
    throw new InvalidOperationException("Invalid criterion.");
}

Eric Lippertの言葉を引用しますが、その答えは主題に関してはかなり明確です。

合理的な質問は、「なぜこれが合法ではないのですか？」です。合理的な答えは「まあ、なぜそうなのか」です。2つの方法のいずれかを使用できます。これは合法です：

switch(y) 
{ 
    case 1:  int x = 123; ...  break; 
    case 2:  int x = 456; ...  break; 
}

またはこれは合法です：

switch(y) 
{
    case 1:  int x = 123; ... break; 
    case 2:  x = 456; ... break; 
}

しかし、両方の方法を使用することはできません。C＃の設計者は、より自然な方法であると思われる2番目の方法を選択しました。

この決定は、わずか10年前の1999年7月7日に行われました。その日のメモのコメントは非常に短く、「スイッチケースは独自の宣言スペースを作成しません」と述べ、何が機能して何が機能しないかを示すサンプルコードを提供します。

この特定の日にデザイナーの心にあったことをもっと知るには、10年前に考えていたことについて多くの人々をバグにしなければならず、最終的に些細な問題についてバグを立てる必要があります。私はそうするつもりはありません。

つまり、いずれかの方法を選択する特に説得力のある理由はありません。どちらにもメリットがあります。言語設計チームは、1つを選択する必要があるため、1つの方法を選択しました。彼らが選んだものは私にとって理にかなっているようです。

したがって、1999年のC＃開発者チームにエリックリッパーよりも時間がない限り、正確な理由はわかりません。

説明は簡単です-Cのようなものだからです。C++、Java、C＃のような言語は、慣れ親しむためにswitchステートメントの構文とスコープをコピーしました。

（別の回答で述べたように、C＃の開発者には、ケーススコープに関するこの決定がどのように行われたかについてのドキュメントがありません。 ）

Cでは、caseステートメントはgoto-labelsに似ています。switchステートメントは、計算されたgotoの構文としては本当に優れています。ケースは、スイッチブロックへのエントリポイントを定義します。デフォルトでは、明示的な終了がない限り、残りのコードが実行されます。したがって、同じスコープを使用するだけで理にかなっています。

（より基本的には、Gotoは構造化されていません。コードのセクションを定義または区切るのではなく、ジャンプポイントのみを定義します。したがって、Gotoラベルはスコープを導入できません。）

C＃は構文を保持しますが、各（空でない）case節の後に終了を要求することにより、「フォールスルー」に対する保護手段を導入します。しかし、これはスイッチの考え方を変えます！ケースは、if-elseのブランチのような代替ブランチになりました。これは、各分岐がif-clausesまたは反復句のように独自のスコープを定義することを期待することを意味します。

つまり、これはCの方法であるため、ケースは同じスコープを共有します。しかし、C＃では、gotoターゲットではなく代替ブランチとしてケースを考えるため、奇妙で一貫性がないように見えます。

スコープを見る簡単な方法は、ブロックごとにスコープを考慮すること{}です。

以来switch任意のブロックが含まれていない、それは異なるスコープを持つことができません。