Чи є причина повторного використання змінної C # в передбаченні?

Під час використання лямбда-виразів або анонімних методів у C #, ми повинні насторожено ставитись до доступу до модифікованого підводного завершення . Наприклад:

foreach (var s in strings)
{
   query = query.Where(i => i.Prop == s); // access to modified closure
   ...
}

Через змінене закриття, наведений вище код призведе до того, що всі Whereпропозиції запиту базуються на кінцевому значенні s.

Як пояснено тут , це відбувається тому, що sзмінна, оголошена у foreachциклі вище, перекладається так у компіляторі:

string s;
while (enumerator.MoveNext())
{
   s = enumerator.Current;
   ...
}

замість цього:

while (enumerator.MoveNext())
{
   string s;
   s = enumerator.Current;
   ...
}

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

string s;
while (enumerator.MoveNext())
{
   s = enumerator.Current;
   ...
}
var finalString = s;

Однак змінні, визначені в foreachциклі, не можна використовувати поза циклом:

foreach(string s in strings)
{
}
var finalString = s; // won't work: you're outside the scope.

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

Чи можна щось зробити з foreachциклами таким чином, чого ви не змогли б, якщо вони були складені із змінною внутрішнього діапазону, або це просто довільний вибір, який було зроблено до того, як анонімні методи та лямбда-вирази були доступні чи поширені, і що не з тих пір не переглядали?

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

Ваша критика цілком виправдана.

Я детально обговорюю цю проблему тут:

Закриття змінної циклу вважається шкідливим

Чи можна зробити щось із циклами foreach таким чином, чого ви не змогли, якщо вони були складені із змінної внутрішньої області? або це лише довільний вибір, який було зроблено до того, як анонімні методи та лямбда-вирази були доступні або поширені, і який з тих пір не переглядався?

Лист. Специфікація C # 1.0 насправді не говорить про те, чи була змінна циклу всередині або поза тілом циклу, оскільки вона не мала помітних змін. Коли в C # 2.0 було введено семантику закриття, було зроблено вибір, щоб поставити змінну циклу поза циклом, що відповідає циклу "для".

Я думаю, що справедливо сказати, що всі шкодують про це рішення. Це один із найгірших "готчей" у C #, і ми будемо приймати переломні зміни, щоб виправити це. У C # 5 змінна циклу foreach буде логічно всередині корпусу циклу, і тому закриття будуть отримувати нову копію кожного разу.

forЦикл не буде змінений, і зміна не буде «назад перенести» в попередні версії C #. Тому слід продовжувати бути обережними, використовуючи цю фразу.

Те, що ви запитуєте, докладно висвітлює Ерік Ліпперт у своєму дописі на блозі Закриття змінної циклу, що вважається шкідливою, та її продовження.

Для мене найбільш переконливим аргументом є те, що наявність нової змінної в кожній ітерації було б невідповідно for(;;)стилю циклу. Чи очікуєте ви нового int iу кожній ітерації for (int i = 0; i < 10; i++)?

Найпоширенішою проблемою такої поведінки є створення перемикання змінної ітерації, і вона має просте вирішення:

foreach (var s in strings)
{
    var s_for_closure = s;
    query = query.Where(i => i.Prop == s_for_closure); // access to modified closure

Мій пост у блозі про цю проблему: Закриття змінної foreach у C # .

Укушений цим, я маю звичку включати локально визначені змінні в найпотужніший обсяг, який я використовую для передачі до будь-якого закриття. У вашому прикладі:

foreach (var s in strings)
    query = query.Where(i => i.Prop == s); // access to modified closure

Я згоден:

foreach (var s in strings)
{
    string search = s;
    query = query.Where(i => i.Prop == search); // New definition ensures unique per iteration.
}        

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

У C # 5.0 ця проблема виправлена, і ви можете закрити змінні циклу та отримати очікувані результати.

Специфікація мови говорить:

8.8.4 Заява foreach

(...)

Формальна заява форми

foreach (V v in x) embedded-statement

Потім розширюється до:

{
  E e = ((C)(x)).GetEnumerator();
  try {
      while (e.MoveNext()) {
          V v = (V)(T)e.Current;
          embedded-statement
      }
  }
  finally {
      … // Dispose e
  }
}

(...)

Розміщення vвсередині циклу while є важливим для того, як його фіксує будь-яка анонімна функція, що виникає у вбудованому операторі. Наприклад:

int[] values = { 7, 9, 13 };
Action f = null;
foreach (var value in values)
{
    if (f == null) f = () => Console.WriteLine("First value: " + value);
}
f();

Якщо це vбуло оголошено за межами циклу while, воно поділялося б між усіма ітераціями, а його значення після циклу for було б остаточним значенням 13, яке саме fдрукує виклик . Натомість, оскільки кожна ітерація має свою змінну v, ця, захоплена fв першій ітерації, продовжує утримувати значення 7, яке буде надруковано. ( Примітка: попередні версії C #, оголошені vпоза циклом while. )