Por que não há método de extensão ForEach no IEnumerable?

Inspirado por outra pergunta sobre a Zipfunção ausente :

Por que não há ForEachmétodo de extensão na Enumerableclasse? Ou em qualquer lugar? A única classe que obtém um ForEachmétodo é List<>. Existe uma razão pela qual está faltando (desempenho)?

Já existe uma declaração foreach incluída no idioma que faz o trabalho a maior parte do tempo.

Eu odiaria ver o seguinte:

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

Ao invés de:

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

O último é mais claro e fácil de ler na maioria das situações , embora talvez um pouco mais longo para digitar.

No entanto, devo admitir que mudei de posição sobre esse assunto; um método de extensão ForEach () seria realmente útil em algumas situações.

Aqui estão as principais diferenças entre a declaração e o método:

• Verificação de tipo: foreach é feito em tempo de execução, ForEach () está em tempo de compilação (Big Plus!)
• A sintaxe para chamar um delegado é realmente muito mais simples: objects.ForEach (DoSomething);
• ForEach () pode ser encadeado: embora a maldade / utilidade de tal recurso esteja aberta à discussão.

Esses são todos os pontos importantes apresentados por muitas pessoas aqui e posso ver por que as pessoas estão perdendo a função. Eu não me importaria de a Microsoft adicionar um método ForEach padrão na próxima iteração de estrutura.

O método ForEach foi adicionado antes do LINQ. Se você adicionar a extensão ForEach, ela nunca será chamada para instâncias da Lista devido às restrições dos métodos de extensão. Eu acho que a razão de não ter sido adicionado é não interferir com o existente.

No entanto, se você realmente sentir falta dessa pequena função, poderá lançar sua própria versão

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

Você pode escrever este método de extensão:

// 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;
    }
}

Prós

Permite encadeamento:

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

Contras

Na verdade, não fará nada até você fazer algo para forçar a iteração. Por esse motivo, não deve ser chamado .ForEach(). Você poderia escrever .ToList()no final ou também este método de extensão:

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

    return source;
}

Isso pode ser um desvio muito significativo das bibliotecas C # de remessa; leitores que não estão familiarizados com seus métodos de extensão não saberão o que fazer com seu código.

A discussão aqui dá a resposta:

Na verdade, a discussão específica que testemunhei dependia de fato da pureza funcional. Em uma expressão, há frequentemente suposições sobre não ter efeitos colaterais. Ter o ForEach é especificamente convidar efeitos colaterais ao invés de apenas tolerá-los. - Keith Farmer (Parceiro)

Basicamente, foi tomada a decisão de manter os métodos de extensão funcionalmente "puros". Um ForEach incentivaria efeitos colaterais ao usar os métodos de extensão Enumerable, que não eram a intenção.

Embora eu concorde que é melhor usar a construção foreachinterna na maioria dos casos, acho que o uso dessa variação na extensão ForEach <> é um pouco melhor do que ter que gerenciar o índice regularmente 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));

Daria a você:

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

Uma solução alternativa é escrever .ToList().ForEach(x => ...).

profissionais

Fácil de entender - o leitor precisa apenas saber o que é fornecido com o C #, não quaisquer métodos de extensão adicionais.

O ruído sintático é muito leve (apenas adiciona um pouco de código extranioso).

Geralmente, não custa memória extra, pois um nativo .ForEach()precisaria realizar toda a coleção.

contras

A ordem das operações não é ideal. Prefiro perceber um elemento, depois agir sobre ele e depois repetir. Esse código realiza todos os elementos primeiro e depois age sobre eles em sequência.

Se a realização da lista gera uma exceção, você nunca age em um único elemento.

Se a enumeração for infinita (como os números naturais), você estará sem sorte.

Eu sempre me perguntei isso, é por isso que sempre carrego isso comigo:

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);
    }
}

Bom pequeno método de extensão.

Portanto, houve muitos comentários sobre o fato de um método de extensão ForEach não ser apropriado, pois não retorna um valor como os métodos de extensão LINQ. Embora essa seja uma afirmação factual, não é inteiramente verdade.

Todos os métodos de extensão LINQ retornam um valor para que possam ser encadeados:

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

No entanto, apenas porque o LINQ é implementado usando métodos de extensão não significa que os métodos de extensão devem ser usados ​​da mesma maneira e retornar um valor. Escrever um método de extensão para expor funcionalidades comuns que não retornam um valor é um uso perfeitamente válido.

O argumento específico sobre o ForEach é que, com base nas restrições dos métodos de extensão (ou seja, que um método de extensão nunca substituirá um método herdado com a mesma assinatura ), pode haver uma situação em que o método de extensão personalizado esteja disponível em todas as classes que impelem IEnumerable <T> exceto Lista <T>. Isso pode causar confusão quando os métodos começam a se comportar de maneira diferente, dependendo se o método de extensão ou o método de herança está sendo chamado ou não.

Você pode usar o (encadeado, mas preguiçosamente avaliado) Select, primeiro fazendo sua operação e depois retornando a identidade (ou qualquer outra coisa, se preferir)

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

Você precisará garantir que ele ainda seja avaliado, seja com Count()(a operação mais barata para enumerar afaik) ou com outra operação necessária.

Eu adoraria vê-lo trazido para a biblioteca padrão:

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

O código acima torna- people.WithLazySideEffect(p => Console.WriteLine(p))se efetivamente equivalente ao foreach, mas preguiçoso e encadeado.

Observe que o MoreLINQ NuGet fornece o ForEachmétodo de extensão que você está procurando (bem como um Pipemétodo que executa o delegado e produz o resultado). Vejo:

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

@Coincoin

O poder real do método de extensão foreach envolve a reutilização do Action<>sem adicionar métodos desnecessários ao seu código. Diga que você tem 10 listas e deseja executar a mesma lógica nelas, e uma função correspondente não se encaixa na sua classe e não é reutilizada. Em vez de ter dez para loops ou uma função genérica que obviamente é um auxiliar que não pertence, você pode manter toda a sua lógica em um só lugar (a Action<>. Assim, dezenas de linhas são substituídas por

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

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

etc ...

A lógica está em um só lugar e você não poluiu sua classe.

A maioria dos métodos de extensão LINQ retorna resultados. O ForEach não se encaixa nesse padrão, pois não retorna nada.

Se você tiver F # (que estará na próxima versão do .NET), poderá usar

Seq.iter doSomething myIEnumerable

Parcialmente, é porque os designers da linguagem discordam de uma perspectiva filosófica.

• Não ter (e testar ...) um recurso é menos trabalhoso do que ter um recurso.
• Não é realmente mais curto (há alguns casos de função de passagem onde está, mas esse não seria o uso principal).
• Seu objetivo é ter efeitos colaterais, que não são sobre o que é linq.
• Por que ter outra maneira de fazer a mesma coisa que um recurso que já temos? (palavra-chave foreach)

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

Você pode usar select quando quiser retornar algo. Caso contrário, você pode usar o ToList primeiro, porque provavelmente não deseja modificar nada na coleção.

Eu escrevi um post sobre isso: http://blogs.msdn.com/kirillosenkov/archive/2009/01/31/foreach.aspx

Você pode votar aqui se quiser ver esse método no .NET 4.0: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=279093

Na 3.5, todos os métodos de extensão adicionados ao IEnumerable estão disponíveis para suporte a LINQ (observe que eles estão definidos na classe System.Linq.Enumerable). Neste post, explico por que o foreach não pertence ao LINQ: método de extensão LINQ existente semelhante ao Parallel.For?

Sou eu ou é a Lista <T> .Foreach praticamente se tornou obsoleta pelo Linq. Originalmente havia

foreach(X x in Y) 

onde Y simplesmente tinha que ser IEnumerable (Pre 2.0) e implementar um GetEnumerator (). Se você olhar para o MSIL gerado, poderá ver que é exatamente o mesmo que

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

    Console.WriteLine(i);
}

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

Então, no DotNet2.0 Generics, apareceu a lista. Foreach sempre me pareceu uma implementação do padrão Vistor (veja Design Patterns de Gamma, Helm, Johnson, Vlissides).

Agora, é claro que na versão 3.5, podemos usar um Lambda para o mesmo efeito; por exemplo, tente http://dotnet-developments.blogs.techtarget.com/2008/09/02/iterators-lambda-and-linq-oh- meu/

Eu gostaria de expandir a resposta de Aku .

Se você quiser chamar um método com o único objetivo de seu efeito colateral sem iterar todo o enumerável primeiro, poderá usar isso:

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

Ninguém ainda apontou que o ForEach <T> resulta na verificação do tipo de tempo de compilação em que a palavra-chave foreach é verificada em tempo de execução.

Depois de fazer uma refatoração em que os dois métodos foram usados ​​no código, sou a favor do .ForEach, pois tive que procurar falhas de teste / falhas de tempo de execução para encontrar os problemas do foreach.