¿Hay alguna razón para la reutilización de C # de la variable en un foreach?

Cuando se utilizan expresiones lambda o métodos anónimos en C #, debemos ser cautelosos con respecto al acceso a errores de cierre modificados . Por ejemplo:

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

Debido al cierre modificado, el código anterior hará que todas las Wherecláusulas de la consulta se basen en el valor final de s.

Como se explica aquí , esto sucede porque la svariable declarada en el foreachbucle anterior se traduce así en el compilador:

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

en lugar de esto:

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

Como se señaló aquí , no hay ventajas de rendimiento para declarar una variable fuera del ciclo, y en circunstancias normales, la única razón que puedo pensar para hacerlo es si planea usar la variable fuera del alcance del ciclo:

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

Sin embargo, las variables definidas en un foreachbucle no pueden usarse fuera del bucle:

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

Por lo tanto, el compilador declara la variable de una manera que lo hace muy propenso a un error que a menudo es difícil de encontrar y depurar, sin producir beneficios perceptibles.

¿Hay algo que puede hacer con los foreachbucles de esta manera que no podría si se compilaran con una variable de alcance interno, o es solo una elección arbitraria que se hizo antes de que los métodos anónimos y las expresiones lambda estuvieran disponibles o fueran comunes, y que no ¿ha sido revisado desde entonces?

El compilador declara la variable de una manera que la hace muy propensa a un error que a menudo es difícil de encontrar y depurar, sin producir beneficios perceptibles.

Su crítica está completamente justificada.

Discuto este problema en detalle aquí:

Cerrar sobre la variable de bucle considerado dañino

¿Hay algo que pueda hacer con los bucles foreach de esta manera que no podría hacer si se compilaran con una variable de alcance interno? ¿O es solo una elección arbitraria que se hizo antes de que los métodos anónimos y las expresiones lambda estuvieran disponibles o fueran comunes, y que no se ha revisado desde entonces?

El último. La especificación C # 1.0 en realidad no decía si la variable del bucle estaba dentro o fuera del cuerpo del bucle, ya que no había ninguna diferencia observable. Cuando se introdujo la semántica de cierre en C # 2.0, se tomó la decisión de colocar la variable del bucle fuera del bucle, de manera consistente con el bucle "for".

Creo que es justo decir que todos lamentan esa decisión. Esta es una de las peores "trampas" en C #, y vamos a tomar el cambio más reciente para solucionarlo. En C # 5, la variable de bucle foreach estará lógicamente dentro del cuerpo del bucle y, por lo tanto, los cierres obtendrán una copia nueva cada vez.

El forbucle no se cambiará y el cambio no se "trasladará" a versiones anteriores de C #. Por lo tanto, debe seguir teniendo cuidado al usar este idioma.

Lo que estás preguntando está completamente cubierto por Eric Lippert en su publicación de blog Cierre sobre la variable de bucle considerada dañina y su secuela.

Para mí, el argumento más convincente es que tener una nueva variable en cada iteración sería inconsistente con el for(;;)bucle de estilo. ¿Esperarías tener una nueva int ien cada iteración de for (int i = 0; i < 10; i++)?

El problema más común con este comportamiento es cerrar la variable de iteración y tiene una solución fácil:

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

Mi publicación de blog sobre este tema: Cierre sobre la variable foreach en C # .

Habiendo sido mordido por esto, tengo la costumbre de incluir variables definidas localmente en el ámbito más interno que utilizo para transferir a cualquier cierre. En tu ejemplo:

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

Hago:

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

Una vez que tenga ese hábito, puede evitarlo en el caso muy raro en el que realmente pretendía unirse a los ámbitos externos. Para ser sincero, no creo haberlo hecho nunca.

En C # 5.0, este problema se soluciona y puede cerrar las variables de bucle y obtener los resultados que espera.

La especificación del lenguaje dice:

8.8.4 La declaración foreach

(...)

Una declaración foreach de la forma

foreach (V v in x) embedded-statement

luego se expande a:

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

(...)

La ubicación vdentro del ciclo while es importante para la forma en que es capturada por cualquier función anónima que ocurra en la declaración incrustada. Por ejemplo:

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

Si vse declarara fuera del ciclo while, se compartiría entre todas las iteraciones, y su valor después del ciclo for sería el valor final 13, que es lo fque imprimiría la invocación de . En cambio, debido a que cada iteración tiene su propia variable v, la capturada fen la primera iteración continuará manteniendo el valor 7, que es lo que se imprimirá. ( Nota: versiones anteriores de C # declaradas vfuera del bucle while ) .