¿Por qué no hay un método de extensión ForEach en IEnumerable?

Inspirado por otra pregunta sobre la Zipfunción que falta :

¿Por qué no hay un ForEachmétodo de extensión en la Enumerableclase? O en cualquier lugar? La única clase que obtiene un ForEachmétodo es List<>. ¿Hay alguna razón por la que falta (rendimiento)?

Ya hay una declaración foreach incluida en el lenguaje que hace el trabajo la mayor parte del tiempo.

Odiaría ver lo siguiente:

list.ForEach( item =>
{
    item.DoSomething();
} );

En vez de:

foreach(Item item in list)
{
     item.DoSomething();
}

Este último es más claro y más fácil de leer en la mayoría de las situaciones , aunque quizás sea un poco más largo para escribir.

Sin embargo, debo admitir que cambié mi postura sobre ese tema; un método de extensión ForEach () sería realmente útil en algunas situaciones.

Estas son las principales diferencias entre la declaración y el método:

• Verificación de tipos: foreach se realiza en tiempo de ejecución, ForEach () está en tiempo de compilación (¡Big Plus!)
• La sintaxis para llamar a un delegado es, de hecho, mucho más simple: objects.ForEach (DoSomething);
• ForEach () podría estar encadenado: aunque la maldad / utilidad de dicha característica está abierta a discusión.

Esos son todos grandes puntos hechos por muchas personas aquí y puedo ver por qué las personas no tienen la función. No me importaría que Microsoft agregue un método ForEach estándar en la próxima iteración del marco.

El método ForEach se agregó antes de LINQ. Si agrega la extensión ForEach, nunca se llamará para instancias de Lista debido a restricciones de métodos de extensión. Creo que la razón por la que no se agregó es para no interferir con el existente.

Sin embargo, si realmente echa de menos esta pequeña y agradable función, puede implementar su propia versión

public static void ForEach<T>(
    this IEnumerable<T> source,
    Action<T> action)
{
    foreach (T element in source) 
        action(element);
}

Podrías escribir este método de extensión:

// Possibly call this "Do"
IEnumerable<T> Apply<T> (this IEnumerable<T> source, Action<T> action)
{
    foreach (var e in source)
    {
        action(e);
        yield return e;
    }
}

Pros

Permite encadenar:

MySequence
    .Apply(...)
    .Apply(...)
    .Apply(...);

Contras

En realidad, no hará nada hasta que haga algo para forzar la iteración. Por esa razón, no debería llamarse .ForEach(). Podrías escribir.ToList() al final, o también podría escribir este método de extensión:

// possibly call this "Realize"
IEnumerable<T> Done<T> (this IEnumerable<T> source)
{
    foreach (var e in source)
    {
        // do nothing
        ;
    }

    return source;
}

Esto puede ser una desviación demasiado significativa de las bibliotecas C # de envío; Los lectores que no estén familiarizados con sus métodos de extensión no sabrán qué hacer con su código.

La discusión aquí da la respuesta:

En realidad, la discusión específica que presencié realmente dependía de la pureza funcional. En una expresión, con frecuencia se hacen suposiciones acerca de no tener efectos secundarios. Tener ForEach es específicamente invitar a los efectos secundarios en lugar de simplemente tolerarlos. - Keith Farmer (socio)

Básicamente, se tomó la decisión de mantener los métodos de extensión funcionalmente "puros". Un ForEach fomentaría los efectos secundarios al usar los métodos de extensión Enumerable, que no era la intención.

Si bien estoy de acuerdo en que es mejor usar la construcción incorporada foreachen la mayoría de los casos, creo que el uso de esta variación en la extensión ForEach <> es un poco mejor que tener que administrar el índice de forma regular foreach:

public static int ForEach<T>(this IEnumerable<T> list, Action<int, T> action)
{
    if (action == null) throw new ArgumentNullException("action");

    var index = 0;

    foreach (var elem in list)
        action(index++, elem);

    return index;
}

var people = new[] { "Moe", "Curly", "Larry" };
people.ForEach((i, p) => Console.WriteLine("Person #{0} is {1}", i, p));

Te daría:

Person #0 is Moe
Person #1 is Curly
Person #2 is Larry

Una solución alternativa es escribir .ToList().ForEach(x => ...).

pros

Fácil de entender: el lector solo necesita saber qué se incluye con C #, no ningún método de extensión adicional.

El ruido sintáctico es muy leve (solo agrega un poco de código extranjero).

Por lo general, no cuesta memoria adicional, ya que un nativo .ForEach()tendría que realizar toda la colección, de todos modos.

contras

El orden de las operaciones no es ideal. Prefiero darme cuenta de un elemento, luego actuar sobre él, luego repetir. Este código realiza primero todos los elementos, luego actúa sobre cada uno de ellos en secuencia.

Si darse cuenta de que la lista arroja una excepción, nunca puede actuar sobre un solo elemento.

Si la enumeración es infinita (como los números naturales), no tienes suerte.

Siempre me lo he preguntado, es por eso que siempre llevo esto conmigo:

public static void ForEach<T>(this IEnumerable<T> col, Action<T> action)
{
    if (action == null)
    {
        throw new ArgumentNullException("action");
    }
    foreach (var item in col)
    {
        action(item);
    }
}

Pequeño y agradable método de extensión.

Así que ha habido muchos comentarios sobre el hecho de que un método de extensión ForEach no es apropiado porque no devuelve un valor como los métodos de extensión LINQ. Si bien esta es una declaración de hechos, no es del todo cierto.

Todos los métodos de extensión LINQ devuelven un valor para que puedan encadenarse:

collection.Where(i => i.Name = "hello").Select(i => i.FullName);

Sin embargo, el hecho de que LINQ se implemente utilizando métodos de extensión no significa que los métodos de extensión deben usarse de la misma manera y devolver un valor. Escribir un método de extensión para exponer una funcionalidad común que no devuelve un valor es un uso perfectamente válido.

El argumento específico sobre ForEach es que, en función de las restricciones en los métodos de extensión (es decir, que un método de extensión nunca anulará un método heredado con la misma firma ), puede haber una situación en la que el método de extensión personalizado esté disponible en todas las clases que imponen IEnumerable <T> excepto Lista <T>. Esto puede causar confusión cuando los métodos comienzan a comportarse de manera diferente dependiendo de si se llama o no al método de extensión o al método de herencia.

Puede usar el (encadenable, pero evaluado perezosamente) Select, primero haciendo su operación y luego devolviendo la identidad (o algo más si lo prefiere)

IEnumerable<string> people = new List<string>(){"alica", "bob", "john", "pete"};
people.Select(p => { Console.WriteLine(p); return p; });

Deberá asegurarse de que todavía se evalúa, ya sea con Count()(la operación más barata para enumerar afaik) u otra operación que necesita de todos modos.

Sin embargo, me encantaría verlo en la biblioteca estándar:

static IEnumerable<T> WithLazySideEffect(this IEnumerable<T> src, Action<T> action) {
  return src.Select(i => { action(i); return i; } );
}

El código anterior se convierte en lo people.WithLazySideEffect(p => Console.WriteLine(p))que es efectivamente equivalente a foreach, pero vago y encadenable.

Tenga en cuenta que MoreLINQ NuGet proporciona el ForEachmétodo de extensión que está buscando (así como un Pipemétodo que ejecuta el delegado y produce su resultado). Ver:

• https://www.nuget.org/packages/morelinq
• https://code.google.com/p/morelinq/wiki/OperatorsOverview

@Coincoin

El poder real del método de extensión foreach implica la reutilización de la Action<>sin agregar métodos innecesarios a su código. Digamos que tiene 10 listas y desea realizar la misma lógica en ellas, y una función correspondiente no cabe en su clase y no se reutiliza. En lugar de tener diez para bucles, o una función genérica que obviamente es una ayuda que no pertenece, puede mantener toda su lógica en un solo lugar (el Action<>. Entonces, docenas de líneas se reemplazan con

Action<blah,blah> f = { foo };

List1.ForEach(p => f(p))
List2.ForEach(p => f(p))

etc ...

La lógica está en un lugar y no has contaminado tu clase.

La mayoría de los métodos de extensión LINQ devuelven resultados. ForEach no se ajusta a este patrón ya que no devuelve nada.

Si tiene F # (que estará en la próxima versión de .NET), puede usar

Seq.iter doSomething myIEnumerable

Parcialmente es porque los diseñadores del lenguaje no están de acuerdo con él desde una perspectiva filosófica.

• No tener (y probar ...) una característica es menos trabajo que tener una característica.
• No es realmente más corto (hay algunos casos de función de paso donde está, pero ese no sería el uso principal).
• Su propósito es tener efectos secundarios, que no es de lo que se trata linq.
• ¿Por qué tener otra forma de hacer lo mismo que una función que ya tenemos? (palabra clave foreach)

https://blogs.msdn.microsoft.com/ericlippert/2009/05/18/foreach-vs-foreach/

Puedes usar select cuando quieras devolver algo. Si no lo hace, puede usar ToList primero, porque probablemente no quiera modificar nada en la colección.

Escribí una publicación de blog al respecto: http://blogs.msdn.com/kirillosenkov/archive/2009/01/31/foreach.aspx

Puede votar aquí si desea ver este método en .NET 4.0: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=279093

En 3.5, todos los métodos de extensión agregados a IEnumerable están ahí para el soporte de LINQ (tenga en cuenta que están definidos en la clase System.Linq.Enumerable). En esta publicación, explico por qué foreach no pertenece a LINQ: método de extensión LINQ existente similar a Parallel.For?

¿Soy yo o la Lista <T>? Por lo tanto, Linq ha dejado obsoleta. Originalmente hubo

foreach(X x in Y) 

donde Y simplemente tenía que ser IEnumerable (Pre 2.0) e implementar un GetEnumerator (). Si observa el MSIL generado, puede ver que es exactamente igual a

IEnumerator<int> enumerator = list.GetEnumerator();
while (enumerator.MoveNext())
{
    int i = enumerator.Current;

    Console.WriteLine(i);
}

(Ver http://alski.net/post/0a-for-foreach-forFirst-forLast0a-0a-.aspx para el MSIL)

Luego, en DotNet2.0, aparecieron los genéricos y la lista. Foreach siempre me ha parecido una implementación del patrón Vistor (ver Patrones de diseño de Gamma, Helm, Johnson, Vlissides).

Ahora, por supuesto, en 3.5 podemos usar una Lambda con el mismo efecto, por ejemplo, intente http://dotnet-developments.blogs.techtarget.com/2008/09/02/iterators-lambda-and-linq-oh- mi/

Me gustaría ampliar la respuesta de Aku .

Si desea llamar a un método con el único propósito de su efecto secundario sin iterar todo el enumerable primero, puede usar esto:

private static IEnumerable<T> ForEach<T>(IEnumerable<T> xs, Action<T> f) {
    foreach (var x in xs) {
        f(x); yield return x;
    }
}

Nadie ha señalado aún que ForEach <T> resulta en la verificación del tipo de tiempo de compilación donde se verifica la palabra clave foreach en tiempo de ejecución.

Después de realizar algunas refactorizaciones donde se utilizaron ambos métodos en el código, estoy a favor de .ForEach, ya que tuve que buscar fallas de prueba / fallas de tiempo de ejecución para encontrar los problemas foreach.