Чому на IEnumerable не існує методу розширення ForEach?

Натхненний ще одним запитанням про відсутність Zipфункції:

Чому ForEachв Enumerableкласі немає методу розширення ? Або де завгодно? Єдиний клас, який отримує ForEachметод, - це List<>. Чи є причина, чому вона відсутня (виконання)?

У мові, яка робить цю роботу більшу частину часу, вже є заява про передбачення.

Мені б не хотілося бачити наступне:

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

Замість:

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

Останнє чіткіше і легше читати в більшості ситуацій , хоча, можливо, трохи довше вводити текст.

Однак, маю визнати, я змінив свою позицію з цього приводу; Метод розширення ForEach () дійсно був би корисним у деяких ситуаціях.

Ось основні відмінності між оператором та методом:

• Перевірка типу: foreach робиться під час виконання, ForEach () знаходиться під час компіляції (Big Plus!)
• Синтаксис виклику делегата дійсно набагато простіший: object.ForEach (DoSomething);
• ForEach () може бути прикутий: хоча злість / корисність такої функції є відкритою для обговорення.

Це все великі моменти, які багато людей тут роблять, і я бачу, чому люди не вистачають цієї функції. Я не заперечую, щоб Microsoft додав стандартний метод ForEach у наступній ітерації фрейму.

Метод ForEach був доданий перед LINQ. Якщо ви додасте розширення ForEach, воно ніколи не буде викликано для екземплярів List через обмеження методів розширення. Я думаю, що причина його не було додано - це не втручання в існуюче.

Однак якщо ви справді не вистачаєте цієї маленької приємної функції, ви можете розгорнути свою власну версію

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

Ви можете написати цей метод розширення:

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

Плюси

Дозволяє ланцюжок:

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

Мінуси

Він насправді нічого не зробить, поки ви щось не змусите ітерацію. З цієї причини його не слід називати .ForEach(). Ви можете написати .ToList()в кінці, або ви також можете написати цей метод розширення:

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

    return source;
}

Це може бути занадто значним відхиленням від бібліотек C # для доставки; читачі, які не знайомі з вашими методами розширення, не знають, що робити з вашим кодом.

Тут обговорення дає відповідь:

Власне, конкретна дискусія, якою я був свідком, насправді залежала від функціональної чистоти. У виразі часто виникають припущення про відсутність побічних ефектів. Надання ForEach спеціально запрошує побічні ефекти, а не просто миритися з ними. - Кіт Фармер (партнер)

В основному було прийнято рішення зберегти методи розширення функціонально "чистими". A ForEach буде заохочувати побічні ефекти при використанні методів розширення безлічі, що не було наміром.

Хоча я згоден, що foreachв більшості випадків краще використовувати вбудовану конструкцію, я вважаю, що використання цієї зміни в розширенні ForEach <> трохи приємніше, ніж самостійно керувати індексом 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));

Дамо вам:

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

Одне вирішення - писати .ToList().ForEach(x => ...).

плюси

Легко зрозуміти - читачеві потрібно лише знати, що постачається з C #, а не якимись додатковими методами розширення.

Синтаксичний шум дуже м'який (лише додає трохи вигідного коду).

Зазвичай це не коштує додаткової пам’яті, оскільки рідному .ForEach()доведеться реалізувати всю колекцію.

мінуси

Порядок операцій не ідеальний. Я вважаю за краще реалізувати один елемент, потім діяти на ньому, а потім повторити. Цей код спочатку реалізує всі елементи, а потім діє на них кожен послідовно.

Якщо реалізація списку кидає виняток, ви ніколи не дієте на один елемент.

Якщо перерахунок нескінченний (як натуральні числа), вам не пощастило.

Мені завжди було цікаво, що я сам, тому я завжди ношу це з собою:

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

Хороший маленький метод розширення.

Отже, було багато коментарів щодо того, що метод розширення ForEach не підходить, оскільки він не повертає значення, як методи розширення LINQ. Хоча це фактичне твердження, воно не зовсім вірно.

Усі методи розширення LINQ повертають значення, щоб вони могли бути пов'язані між собою:

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

Однак те, що LINQ реалізовано за допомогою методів розширення, не означає, що методи розширення повинні використовуватися однаково і повертати значення. Написання методу розширення для викриття загальної функціональності, яка не повертає значення, є цілком правильним використанням.

Специфічна аргументація щодо ForEach полягає в тому, що, виходячи з обмежень методів розширення (а саме те, що метод розширення ніколи не замінить успадкований метод з однаковою підписом ), може виникнути ситуація, коли користувацький метод розширення доступний для всіх класів, що імпементують Численні <T> крім списку <T>. Це може викликати плутанину, коли методи починають поводитися по-різному, залежно від того, викликається чи ні метод розширення чи метод успадкування.

Ви можете скористатися (прийнятним, але ліниво оціненим) Select, спочатку зробивши свою операцію, а потім повернувши ідентифікацію (або щось інше, якщо вам зручніше)

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

Вам потрібно буде переконатися, що вона все ще оцінюється, або з Count()(найдешевша операція для перерахування afaik), або з іншою операцією, яка вам потрібна.

Я хотів би, щоб це було внесено до стандартної бібліотеки:

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

Вищенаведений код стає таким, people.WithLazySideEffect(p => Console.WriteLine(p))який фактично еквівалентний передчуттю, але ледачий і вигідний.

Зауважте, що MoreLINQ NuGet пропонує ForEachметод розширення, який ви шукаєте (а також Pipeметод, який виконує делегат і дає його результат). Подивитися:

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

@Coincoin

Реальна сила методу розширення foreach включає повторне використання Action<>без додавання зайвих методів до вашого коду. Скажіть, що у вас є 10 списків і ви хочете виконувати ту саму логіку, і відповідна функція не вписується у ваш клас і не використовується повторно. Замість того, щоб мати десять циклів або загальну функцію, яка, очевидно, є помічником, який не належить, ви можете зберегти всю свою логіку в одному місці ( Action<>. Отже, десятки рядків заміняються на

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

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

тощо ...

Логіка в одному місці, і ви не забруднили свій клас.

Більшість методів розширення LINQ повертають результати. ForEach не вписується в цей шаблон, оскільки він нічого не повертає.

Якщо у вас є F # (який буде в наступній версії .NET), ви можете використовувати

Seq.iter doSomething myIEnumerable

Частково це відбувається тому, що мовні дизайнери не згодні з цим з філософської точки зору.

• Немає (і тестує ...) функцію - це менше роботи, ніж функція.
• Це насправді не коротше (є деякі випадки проходження функцій, де це є, але це не було б основним використанням).
• Його мета полягає в тому, щоб мати побічні ефекти, а це не те, що стосується linq.
• Чому є інший спосіб зробити те ж саме, що і функцію, яку ми вже отримали? (ключове слово foreach)

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

Ви можете використовувати select, коли хочете щось повернути. Якщо цього немає, спочатку ви можете скористатися ToList, оскільки ви, мабуть, не хочете нічого змінювати в колекції.

Я написав про це запис у блозі: http://blogs.msdn.com/kirillosenkov/archive/2009/01/31/foreach.aspx

Ви можете проголосувати тут, якщо хочете бачити цей метод у .NET 4.0: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=279093

У 3.5 всі методи розширення, додані до IEnumerable, існують для підтримки LINQ (зауважте, що вони визначені у класі System.Linq.Enumerable). У цій публікації я пояснюю, чому foreach не належить до LINQ: Існуючий метод розширення LINQ, аналогічний Parallel.For?

Це я чи це Список <T> .Багато більше, Linq зробив застарілим. Спочатку був

foreach(X x in Y) 

де Y просто повинен бути IEnumerable (Pre 2.0) та реалізувати GetEnumerator (). Якщо ви подивитесь на створений MSIL, ви можете побачити, що він точно такий же, як

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

    Console.WriteLine(i);
}

(Дивіться http://alski.net/post/0a-for-foreach-forFirst-forLast0a-0a-.aspx для MSIL)

Потім у DotNet2.0 Generics прийшли разом і Список. Foreach завжди вважав мене втіленням схеми Vistor (див. Шаблони дизайну від Gamma, Helm, Johnson, Vlissides).

Тепер, звичайно, у 3.5 ми можемо замість цього використовувати Lambda з тим же ефектом, наприклад, спробуйте http://dotnet-developments.blogs.techtarget.com/2008/09/02/iterators-lambda-and-linq-oh- мій /

Я хотів би розширити відповідь Аку .

Якщо ви хочете викликати метод з єдиною метою його побічного ефекту без повторення цілого переліку, ви можете скористатися цим:

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

Ніхто ще не вказував, що ForEach <T> приводить до перевірки типу компіляції часу, де перевірено ключове слово foreach.

Зробивши рефакторинг, де обидва способи використовувались у коді, я віддаю перевагу. Для кожного, оскільки мені довелося розшукувати тести / збої в роботі, щоб знайти проблеми передбачення.