Pourquoi l'extension Linq ForEach sur la liste plutôt que sur IEnumerable ?

Question

Duplicata possible :
Pourquoi n'existe-t-il pas une méthode d'extension ForEach sur l'interface IEnumerable ?

Bonjour,

Ma question est de savoir pourquoi la méthode d'extension Foreach est définie sur List plutôt que sur IEnumreable. J'ai lu l'article d'Eric Lippert article mais le fait est que, si c'est si mauvais d'avoir une telle méthode, pourquoi est-elle là pour List ?

Answer 1

List<T>.ForEach() n'est pas une méthode d'extension. C'est juste une méthode sur List<T> .

L'une des principales raisons pour lesquelles elle n'est pas disponible dans LINQ (c'est-à-dire, Enumerable ) est que les requêtes LINQ sont censées être exemptes d'effets secondaires (vous pouvez donc, par exemple, exécuter une requête plusieurs fois et obtenir les mêmes résultats sans les modifier), ce qui les rend très composables. Toutes les opérations LINQ qui acceptent les délégués sont pour Func ; aucun d'entre eux n'accepte un Action délégué.

Answer 2

Il s'agit d'un bogue que j'avais signalé sur le site Web de Microsoft Connect. Microsoft l'a déjà corrigé dans la prochaine édition de .NET, comme indiqué dans le lien suivant.

List.ForEach permet l'énumération sur une version modifiée de List

Ce n'est probablement pas directement lié à la réponse mais c'est assez drôle de ce que je viens de découvrir.

ForEach, supprimer (travaux)

List<int> list = new List<int>(){ 1, 2, 3, 4, 5, 6};

list.ForEach(x => {
    Console.WriteLine(x);
    list.Remove(x);
});

foreach, delete (accidents)

// throws exception
foreach (var x in list)
{
    Console.WriteLine(x);
    list.Remove(x);
}

ForEach, insérer (...)

// goes in infinite loop...
list.ForEach(x => {
    list.Add(1);
});

foreach, insert (accidents)

// throws exception
foreach (var x in list)
{
    Console.WriteLine(x);
    list.Add(x);
}

Donc tous ceux qui parlent ici de mutabilité ou de différentes couches de confusion, etc., je pense qu'il s'agit d'une fonctionnalité complètement à moitié implémentée par Visual Team car l'énumération posera toujours des problèmes si la collection est modifiée.

Malgré les arguments, je ne vois toujours pas pourquoi ForEach devrait permettre des modifications, il est purement utilisé pour l'énumération et cela ne fait aucune différence que ce soit la syntaxe foreach(var item in x) ou x.ForEach(x=>{}).

Je ne suis pas d'accord avec Eric, je vois simplement que l'équipe de la BCL a implémenté cette fonctionnalité sur IEnumerable et que list.ForEach est défectueux.

"Pourquoi" est complètement subjectif, par exemple, Silverlight a ajouté des algorithmes de hachage complexes et a laissé MD5 derrière lui alors que partout ailleurs nous utilisons MD5 si largement. Il s'agit plutôt de savoir à quel point une chose est demandée et qui est celui qui choisit de l'inclure ou non dans le framework.

Il n'y a aucune raison logique ou philosophique de ne pas avoir ForEach dans IEnumerable. Il y a beaucoup de points manquants de ce genre qui, je pense, seront améliorés par .NET avec le temps.

Answer 3

En fait, la mutation d'état à l'aide de LINQ doit être évitée et non encouragée. LINQ se concentre sur l'interrogation et la transformation des données, mais pas sur la mutation sur place - vous perdez beaucoup des avantages de l'approche fonctionnelle de LINQ (c'est-à-dire pas d'effets secondaires, la même entrée produit la même sortie) si vous mutez l'état.

Il n'y a aucun avantage à ce que Linq offre un ForEach() sur une méthode d'extension normale foreach boucle autre que cela vous aiderait à muter l'état - donc il n'est pas implémenté (c'est au moins mon point de vue, prenez-le avec un grain de sel).

Answer 4

Le "pourquoi" n'est pas de mon ressort ; je n'ai pas créé C#. Cependant, cela a du sens, car il va énumérer votre collection de manière complète alors que la plupart des opérateurs LINQ sont évalués de manière paresseuse.