Почему C # не имеет локальной области видимости в случае блоков?

Я писал этот код:

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'

Это было довольно легко решить проблему; просто избавиться от второго varсделал свое дело.

Очевидно, что переменные, объявленные в caseблоках, имеют родительскую область switch, но мне любопытно, почему это так. Учитывая , что C # не позволяет выполнение провалиться других случаях (это требует break , return, throwили goto caseзаявления в конце каждого caseблока), кажется , довольно странно , что это позволило бы объявления переменных в один , 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);
   

   Я получаю « Не могу использовать локальную переменную« действие », прежде чем она объявлена ». Таким образом, порядок использования блоков case здесь важен не совсем очевидным образом. Обычно я могу записывать их в любом порядке, который мне нужен, но поскольку он 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.

Еще одним исключением являются локальные переменные в выражениях запросов LINQ, но они полностью отличаются от обычных объявлений локальных переменных, поэтому я не думаю, что есть вероятность путаницы там.

Для справки, правила приведены в §3.7 Области применения спецификации C #:

• Область локальной переменной, объявленной в объявлении локальной переменной, является блоком, в котором происходит объявление.

• Видимости локальной переменной , объявленной в выключателя блока в виде switchутверждения является включение блока .

• Видимости локальной переменной , объявленной в течение-инициализатора в виде forутверждения является для-инициализатор , то для условие , то для-итератора , и содержится утверждение о forзаявлении.

• Область видимости переменного объявлена как часть Еогеаспа-выписка , используя-заявление , блокировки заявление или запрос-выражение определяется расширением данной конструкции.

(Хотя я не совсем уверен, почему этот 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.");
}

Я процитирую Эрика Липперта, ответ которого достаточно ясен по этому вопросу:

Резонный вопрос "почему это не законно?" Разумный ответ «ну, почему так должно быть»? Вы можете получить это одним из двух способов. Либо это законно

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 # выбрали второй способ, который кажется более естественным.

Это решение было принято 7 июля 1999 года, всего лишь десять лет назад. Комментарии в примечаниях того дня чрезвычайно кратки, просто заявляя, что «switch-case не создает свое собственное пространство объявлений», а затем приводим некоторый пример кода, который показывает, что работает, а что нет.

Чтобы узнать больше о том, что думали дизайнеры в этот конкретный день, мне нужно было бы расспросить многих людей о том, что они думали десять лет назад, и задать им вопрос о том, что в конечном итоге является тривиальной проблемой; Я не собираюсь этого делать.

Короче говоря, нет особой причины выбирать тот или иной путь; оба имеют свои достоинства. Команда языкового дизайна выбрала один путь, потому что им нужно было выбрать один; тот, который они выбрали, кажется мне разумным.

Так что, если вы не работаете в команде разработчиков C # 1999 больше, чем Эрик Липперт, вы никогда не узнаете точную причину!

Объяснение простое - это потому, что это похоже на то, что в C. Такие языки, как C ++, Java и C #, скопировали синтаксис и область видимости оператора switch для удобства.

(Как указано в другом ответе, разработчики C # не имеют документации о том, как было принято это решение в отношении кейс-областей. Но неустановленный принцип для синтаксиса C # заключался в том, что, если у них не было веских причин сделать это по-другому, они копировали Java. )

В C операторы case похожи на goto-label. Оператор switch - действительно лучший синтаксис для вычисляемого перехода . Случаи определяют точки входа в блок переключателей. По умолчанию остальная часть кода будет выполнена, если нет явного выхода. Так что имеет смысл только использовать одну и ту же область.

(Более фундаментально. Goto не структурированы - они не определяют или не разграничивают разделы кода, они только определяют точки перехода. Поэтому метка goto не может вводить область.)

C # сохраняет синтаксис, но вводит защиту от «провала», требуя выхода после каждого (не пустого) предложения case. Но это меняет наше представление о переключателе! Случаи теперь представляют собой альтернативные ветви , как ветви в if-else. Это означает, что мы ожидаем, что каждая ветвь будет определять свою собственную область видимости, как if-предложения или предложения итерации.

Итак, вкратце: дела имеют одинаковую область действия, потому что это то же самое, что и в C. Но это кажется странным и непоследовательным в C #, потому что мы рассматриваем случаи как альтернативные ветви, а не как цели goto.

Упрощенный способ просмотра области видимости заключается в рассмотрении области видимости по блокам {}.

Поскольку switchне содержит никаких блоков, он не может иметь разные области видимости.