Чому у 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.");
    }
}

І був здивований, виявивши помилку компіляції:

Локальна змінна назва "дія" вже визначена в цій області

Вирішити це було досить просто; просто позбувшись другого 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);

   Я отримую " Неможливо використовувати локальну змінну" дія "до того, як вона буде оголошена ". Отже, порядок блоків регістрів тут є важливим таким чином, що не зовсім очевидно - зазвичай я можу писати їх у будь-якому бажаному порядку, але тому, що 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заяві.

• Область змінної, оголошеної частиною оператора foreach , using-statement , lock-statement або query-izraz визначається розширенням даної конструкції.

(Хоча я не зовсім впевнений, чому цей 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 року, лише сором'язливо десять років тому. Зауваження у примітках цього дня є надзвичайно короткими, просто зазначаючи, що "випадок комутації не створює власний простір декларацій", а потім надає деякий зразок коду, який показує, що працює, а що ні.

Щоб дізнатися більше про те, що було в думках дизайнерів у цей конкретний день, мені доведеться клопотати багато людей про те, про що вони думали десять років тому, - і запитати їх про те, що в кінцевому рахунку є тривіальним питанням; Я не збираюся цього робити.

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

Тож, якщо ви більше не будете інтим з командою розробників C # 1999 року, ніж Ерік Ліпперт, ви ніколи не дізнаєтесь точної причини!

Пояснення просте - це тому, що воно подібне до C. Такі мови, як C ++, Java та C #, скопіювали синтаксис та обстеження оператора перемикання заради ознайомлення.

(Як сказано в іншій відповіді, розробники C # не мають документації про те, як було прийнято це рішення щодо обсягів справи. Але нестаціонарний принцип для синтаксису C # полягав у тому, що, якщо у них не було вагомих причин зробити це по-іншому, вони скопіювали Java. )

У З твердженнями регістру подібні до goto-міток. Оператор переключення - це дійсно приємніший синтаксис для обчисленого goto . Випадки визначають точки входу в блок комутатора. За замовчуванням решта коду буде виконана, якщо немає явного виходу. Тож має сенс лише використовувати один і той же обсяг.

(Більш принципово. Goto не структуровані - вони не визначають і не розмежовують розділи коду, вони лише визначають точки стрибків. Тому мітка goto не може ввести область застосування.)

C # зберігає синтаксис, але вводить захист від "проникнення", вимагаючи виходу після кожного (не порожнього) пункту випадку. Але це змінює те, як ми думаємо про вимикач! Тепер справи - це чергові гілки , як гілки в іншому випадку. Це означає, що ми очікуємо, що кожна галузь визначає власну сферу дії, подібно до клавіш if-clause або ітерації.

Отже, коротко: випадки мають однакову сферу застосування, оскільки це так, як у C. Але це здається дивним та непослідовним у C #, тому що ми вважаємо випадки альтернативними гілками, а не гот-цілями.

Спрощений спосіб розгляду сфери - розглянути область застосування за блоками {}.

Оскільки switchне містить блоків, він не може мати різні сфери застосування.