我的版本是一个扩展方法，允许你在T的IEnumerable上使用ForEach

public static class EnumerableExtension
{
        public static void ForEach<T>(this IEnumerable<T> source, Action<T> action)
    {
        source.All(x =>
        {
            action.Invoke(x);
            return true;
        });
    }
}

还没有人指出ForEach<T>导致编译时类型检查，其中ForEach关键字是运行时检查的。

在代码中使用了这两个方法之后，我做了一些重构，我倾向于. foreach，因为我必须查找测试失败/运行时失败来找到foreach问题。

我为此写了一篇博文: http://blogs.msdn.com/kirillosenkov/archive/2009/01/31/foreach.aspx

如果你想在。net 4.0中看到这个方法，你可以在这里投票: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=279093

这里的讨论给出了答案:

实际上，我所看到的具体讨论确实取决于功能的纯洁性。在一个表达式中，经常会有关于没有副作用的假设。使用ForEach是特别吸引副作用，而不仅仅是忍受它们。——基思·法默(合伙人)

基本上，这个决定是为了保持扩展方法在功能上的“纯粹”。ForEach在使用Enumerable扩展方法时会产生副作用，这不是目的。

在该语言中已经包含了一个foreach语句，它在大多数情况下都可以完成这项工作。

我不希望看到以下情况:

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

而不是:

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

后者在大多数情况下更清晰，更容易阅读，尽管可能要长一点打字。

然而，我必须承认我在这个问题上改变了立场;ForEach()扩展方法在某些情况下确实很有用。

下面是语句和方法之间的主要区别:

类型检查:foreach在运行时完成，foreach()在编译时完成(大加分!) 调用委托的语法确实简单得多:objects.ForEach(DoSomething); ForEach()可以被链接:尽管这样一个特性的邪恶/有用还有待讨论。

这些都是很多人提出的很好的观点，我可以理解为什么人们忽略了这个功能。我不介意微软在下一个框架迭代中添加标准ForEach方法。

因此，有很多关于ForEach扩展方法不合适的评论，因为它不像LINQ扩展方法那样返回值。虽然这是事实陈述，但并不完全正确。

LINQ扩展方法都返回一个值，所以它们可以链接在一起:

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

然而，仅仅因为LINQ是使用扩展方法实现的，并不意味着扩展方法必须以相同的方式使用并返回一个值。编写一个扩展方法来公开不返回值的常见功能是完全有效的使用。

关于ForEach的具体参数是，基于扩展方法的约束(即扩展方法永远不会覆盖具有相同签名的继承方法)，可能存在这样一种情况，即自定义扩展方法在所有impelement IEnumerable<T> (List<T>除外)的类上可用。这可能会导致混淆，因为根据调用的是扩展方法还是继承方法，方法开始表现不同。