C'è una ragione per il riutilizzo di C # della variabile in una foreach?

Quando si usano espressioni lambda o metodi anonimi in C #, dobbiamo stare attenti all'accesso alla trappola della chiusura modificata . Per esempio:

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

A causa della chiusura modificata, il codice sopra riportato farà sì che tutte le Whereclausole sulla query siano basate sul valore finale di s.

Come spiegato qui , questo accade perché la svariabile dichiarata nel foreachciclo sopra è tradotta in questo modo nel compilatore:

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

invece di così:

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

Come sottolineato qui , non ci sono vantaggi prestazionali nel dichiarare una variabile al di fuori del ciclo, e in circostanze normali l'unica ragione a cui posso pensare per farlo è se pensi di usare la variabile al di fuori dell'ambito del ciclo:

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

Tuttavia, le variabili definite in un foreachloop non possono essere utilizzate al di fuori del loop:

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

Quindi il compilatore dichiara la variabile in un modo che la rende altamente soggetta a un errore che è spesso difficile da trovare e eseguire il debug, senza produrre benefici percepibili.

C'è qualcosa che puoi fare con i foreachloop in questo modo che non potresti se fossero compilati con una variabile con ambito interno, o è solo una scelta arbitraria che è stata fatta prima che i metodi anonimi e le espressioni lambda fossero disponibili o comuni, e che non ha da allora è stato rivisto?

Il compilatore dichiara la variabile in un modo che la rende altamente soggetta a un errore che è spesso difficile da trovare e eseguire il debug, senza produrre benefici percepibili.

La tua critica è del tutto giustificata.

Discuto questo problema in dettaglio qui:

Chiudere la variabile loop considerata dannosa

C'è qualcosa che puoi fare con foreach loop in questo modo che non potresti se fossero compilati con una variabile con ambito interno? o è solo una scelta arbitraria fatta prima che fossero disponibili o comuni metodi anonimi ed espressioni lambda e che da allora non è stata rivista?

L'ultimo. La specifica C # 1.0 in realtà non diceva se la variabile del loop fosse all'interno o all'esterno del corpo del loop, poiché non faceva alcuna differenza osservabile. Quando la semantica di chiusura è stata introdotta in C # 2.0, è stata fatta la scelta di mettere la variabile del ciclo al di fuori del ciclo, coerentemente con il ciclo "for".

Penso che sia giusto dire che tutti rimpiangono questa decisione. Questo è uno dei peggiori "gotchas" in C #, e prenderemo il cambiamento per risolverlo. In C # 5 la variabile del ciclo foreach sarà logicamente all'interno del corpo del ciclo, e quindi le chiusure riceveranno una nuova copia ogni volta.

Il forciclo non verrà modificato e la modifica non verrà "trasferita" alle versioni precedenti di C #. Dovresti quindi continuare a stare attento quando usi questo linguaggio.

Quello che stai chiedendo è completamente coperto da Eric Lippert nel suo post sul blog. Chiudere la variabile loop considerata dannosa e il suo sequel.

Per me, l'argomento più convincente è che avere una nuova variabile in ogni iterazione sarebbe incompatibile con il for(;;)loop di stile. Ti aspetteresti di avere un nuovo int iin ogni iterazione di for (int i = 0; i < 10; i++)?

Il problema più comune con questo comportamento è la chiusura di una variabile di iterazione e una soluzione semplice:

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

Il mio post sul blog su questo problema: chiusura per foreach variabile in C # .

Essendo stato morso da questo, ho l'abitudine di includere variabili localmente definite nell'ambito più interno che utilizzo per trasferire a qualsiasi chiusura. Nel tuo esempio:

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

Lo voglio:

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

Una volta che hai quell'abitudine, puoi evitarlo nel caso molto raro in cui intendevi legarti agli ambiti esterni. Ad essere sincero, non credo di averlo mai fatto.

In C # 5.0, questo problema è stato risolto e puoi chiudere le variabili di loop e ottenere i risultati che ti aspetti.

La specifica della lingua dice:

8.8.4 L'istruzione foreach

(...)

Una dichiarazione foreach del modulo

foreach (V v in x) embedded-statement

viene quindi espanso in:

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

(...)

Il posizionamento vall'interno del ciclo while è importante per come viene catturato da qualsiasi funzione anonima presente nell'istruzione incorporata. Per esempio:

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

Se vfosse dichiarato al di fuori del ciclo while, sarebbe condiviso tra tutte le iterazioni e il suo valore dopo il ciclo for sarebbe il valore finale 13, che è ciò che l'invocazione fdovrebbe stampare. Invece, poiché ogni iterazione ha una propria variabile v, quella catturata dalla fprima iterazione continuerà a contenere il valore 7, che è ciò che verrà stampato. ( Nota: le versioni precedenti di C # dichiarate val di fuori del ciclo while. )