Perché non esiste un metodo di estensione ForEach su IEnumerable?

Ispirato da un'altra domanda sulla Zipfunzione mancante :

Perché non esiste un ForEachmetodo di estensione nella Enumerableclasse? O ovunque? L'unica classe che ottiene un ForEachmetodo è List<>. C'è un motivo per cui manca (performance)?

Esiste già un'istruzione foreach inclusa nella lingua che svolge il lavoro per la maggior parte del tempo.

Non vorrei vedere quanto segue:

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

Invece di:

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

Quest'ultimo è più chiaro e più facile da leggere nella maggior parte delle situazioni , anche se forse è un po 'più lungo da scrivere.

Tuttavia, devo ammettere di aver cambiato la mia posizione su tale questione; un metodo di estensione ForEach () sarebbe effettivamente utile in alcune situazioni.

Ecco le principali differenze tra l'affermazione e il metodo:

• Controllo del tipo: foreach viene eseguito in fase di esecuzione, ForEach () è in fase di compilazione (Big Plus!)
• La sintassi per chiamare un delegato è davvero molto più semplice: objects.ForEach (DoSomething);
• ForEach () potrebbe essere incatenato: sebbene la malvagità / l'utilità di una tale caratteristica sia aperta alla discussione.

Questi sono tutti ottimi punti sollevati da molte persone qui e posso vedere perché alla gente manca la funzione. Non mi dispiacerebbe che Microsoft aggiungesse un metodo ForEach standard nella prossima iterazione del framework.

Ogni metodo è stato aggiunto prima di LINQ. Se aggiungi l'estensione ForEach, non verrà mai chiamato per le istanze Elenco a causa dei vincoli dei metodi di estensione. Penso che il motivo per cui non è stato aggiunto sia di non interferire con quello esistente.

Tuttavia, se ti manca davvero questa piccola funzione, puoi implementare la tua versione

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

È possibile scrivere questo metodo di estensione:

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

Professionisti

Permette il concatenamento:

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

Contro

In realtà non farà nulla finché non fai qualcosa per forzare l'iterazione. Per questo motivo, non dovrebbe essere chiamato .ForEach(). Potresti scrivere .ToList()alla fine o puoi scrivere anche questo metodo di estensione:

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

    return source;
}

Questo potrebbe essere un allontanamento troppo significativo dalle librerie C # di spedizione; i lettori che non hanno familiarità con i metodi di estensione non sanno cosa fare del codice.

La discussione qui dà la risposta:

In realtà, la discussione specifica a cui ho assistito in effetti dipendeva dalla purezza funzionale. In un'espressione, ci sono spesso ipotesi fatte sul non avere effetti collaterali. Avere ForEach invita in modo specifico gli effetti collaterali piuttosto che tollerarli. - Keith Farmer (Partner)

Fondamentalmente è stata presa la decisione di mantenere i metodi di estensione funzionalmente "puri". Un ForEach incoraggerebbe effetti collaterali quando si utilizzano i metodi di estensione Enumerable, che non era l'intento.

Mentre sono d'accordo che foreachnella maggior parte dei casi è meglio usare il costrutto integrato , trovo che l'uso di questa variazione sull'estensione ForEach <> sia un po 'più bello che dover gestire l'indice in modo regolare 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));

Ti darebbe:

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

Una soluzione alternativa è scrivere .ToList().ForEach(x => ...) .

professionisti

Facile da capire: il lettore deve solo sapere cosa viene fornito con C #, non con altri metodi di estensione.

Il rumore sintattico è molto lieve (aggiunge solo un po 'di codice extranious).

Di solito non costa memoria aggiuntiva, poiché nativo .ForEach() dovrebbe comunque realizzare l'intera collezione.

cons

L'ordine delle operazioni non è l'ideale. Preferirei realizzare un elemento, quindi agire su di esso, quindi ripetere. Questo codice realizza prima tutti gli elementi, quindi agisce su ciascuno di essi in sequenza.

Se la realizzazione dell'elenco genera un'eccezione, non potrai mai agire su un singolo elemento.

Se l'enumerazione è infinita (come i numeri naturali), sei sfortunato.

Mi sono sempre chiesto che io stesso, ecco perché lo porto sempre con me:

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

Bel metodo di estensione.

Quindi ci sono stati molti commenti sul fatto che un metodo di estensione ForEach non è appropriato perché non restituisce un valore come i metodi di estensione LINQ. Mentre questa è un'affermazione di fatto, non è del tutto vera.

I metodi di estensione LINQ restituiscono tutti un valore in modo che possano essere concatenati:

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

Tuttavia, solo perché LINQ è implementato utilizzando i metodi di estensione non significa che i metodi di estensione debbano essere utilizzati allo stesso modo e restituire un valore. Scrivere un metodo di estensione per esporre funzionalità comuni che non restituiscono un valore è un uso perfettamente valido.

L'argomentazione specifica su ForEach è che, in base ai vincoli sui metodi di estensione (ovvero che un metodo di estensione non sostituirà mai un metodo ereditato con la stessa firma ), potrebbe esserci una situazione in cui il metodo di estensione personalizzato è disponibile su tutte le classi che impelement IEnumerable <T> tranne Elenco <T>. Ciò può causare confusione quando i metodi iniziano a comportarsi in modo diverso a seconda che venga chiamato o meno il metodo di estensione o il metodo di ereditarietà.

Puoi usare (concatenabile, ma valutato pigramente) Select, prima facendo la tua operazione e poi restituendo l'identità (o qualcos'altro se preferisci)

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

Dovrai assicurarti che sia ancora valutato, con Count()(l'operazione più economica per enumerare afaik) o con un'altra operazione che ti serviva comunque.

Mi piacerebbe vederlo portato nella libreria standard però:

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

Il codice sopra diventa quindi people.WithLazySideEffect(p => Console.WriteLine(p))che è effettivamente equivalente a foreach, ma pigro e concatenabile.

Nota che MoreLINQ NuGet fornisce il ForEachmetodo di estensione che stai cercando (oltre a un Pipemetodo che esegue il delegato e produce il suo risultato). Vedere:

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

@Coincoin

Il vero potere del metodo di estensione foreach comporta la riusabilità di Action<>senza aggiungere metodi non necessari al codice. Supponi di avere 10 elenchi e desideri eseguire la stessa logica su di essi e che una funzione corrispondente non rientri nella tua classe e non venga riutilizzata. Invece di avere dieci per loop, o una funzione generica che è ovviamente un aiuto che non appartiene, puoi mantenere tutta la tua logica in un posto (il Action<>. Quindi, dozzine di linee vengono sostituite con

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

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

eccetera...

La logica è in un posto e non hai inquinato la tua classe.

La maggior parte dei metodi di estensione LINQ restituisce risultati. Ciascuno non si adatta a questo modello in quanto non restituisce nulla.

Se hai F # (che sarà nella prossima versione di .NET), puoi usare

Seq.iter doSomething myIEnumerable

In parte è perché i progettisti del linguaggio non sono d'accordo con esso da una prospettiva filosofica.

• Non avere (e testare ...) una funzione è meno lavoro che avere una funzione.
• Non è molto più breve (ci sono alcuni casi di funzioni di passaggio in cui si trova, ma non sarebbe l'uso primario).
• Lo scopo è quello di avere effetti collaterali, che non è ciò di cui si occupa linq.
• Perché un altro modo di fare la stessa cosa di una funzione che abbiamo già? (parola chiave foreach)

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

Puoi usare select quando vuoi restituire qualcosa. In caso contrario, è possibile utilizzare prima ToList, perché probabilmente non si desidera modificare nulla nella raccolta.

Ho scritto un post sul blog a riguardo: http://blogs.msdn.com/kirillosenkov/archive/2009/01/31/foreach.aspx

Puoi votare qui se desideri vedere questo metodo in .NET 4.0: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=279093

In 3.5, tutti i metodi di estensione aggiunti a IEnumerable sono disponibili per il supporto LINQ (si noti che sono definiti nella classe System.Linq.Enumerable). In questo post, spiego perché foreach non appartiene a LINQ: metodo di estensione LINQ esistente simile a Parallel.Per?

Sono io o è la lista <T>. La consegna è stata praticamente resa obsoleta da Linq. Inizialmente c'era

foreach(X x in Y) 

dove Y doveva semplicemente essere IEnumerable (Pre 2.0) e implementare un GetEnumerator (). Se guardi il MSIL generato, puoi vedere che è esattamente lo stesso di

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

    Console.WriteLine(i);
}

(Vedi http://alski.net/post/0a-for-foreach-forFirst-forLast0a-0a-.aspx per MSIL)

Quindi in DotNet2.0 sono arrivati ​​i generici e l'elenco. Foreach mi è sempre sembrato un'implementazione del modello Vistor (vedi Design Patterns di Gamma, Helm, Johnson, Vlissides).

Ora ovviamente nella 3.5 possiamo invece usare una Lambda con lo stesso effetto, per esempio provare http://dotnet-developments.blogs.techtarget.com/2008/09/02/iterators-lambda-and-linq-oh- mio/

Vorrei ampliare la risposta di Aku .

Se vuoi chiamare un metodo al solo scopo del suo effetto collaterale senza ripetere prima l'intero elenco enumerabile, puoi usare questo:

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

Nessuno ha ancora sottolineato che ForEach <T> si traduce in un controllo del tipo di tempo di compilazione in cui viene verificata la runtime della parola chiave foreach.

Dopo aver effettuato alcuni refactoring in cui entrambi i metodi sono stati utilizzati nel codice, preferisco. Per ogni motivo, poiché ho dovuto dare la caccia agli errori di test / errori di runtime per trovare i problemi di foreach.