这种方法纯吗？

我有以下扩展方法：

    public static IEnumerable<T> Apply<T>(
        [NotNull] this IEnumerable<T> source,
        [NotNull] Action<T> action)
        where T : class
    {
        source.CheckArgumentNull("source");
        action.CheckArgumentNull("action");
        return source.ApplyIterator(action);
    }

    private static IEnumerable<T> ApplyIterator<T>(this IEnumerable<T> source, Action<T> action)
        where T : class
    {
        foreach (var item in source)
        {
            action(item);
            yield return item;
        }
    }

它只是在返回序列之前对序列的每个项目执行操作。

我想知道是否应该将Pure属性（来自Resharper注释）应用于此方法，并且可以看到支持和反对该参数的参数。

优点：

• 严格来说，它是纯净的；仅在序列上调用它不会更改序列（它返回新序列）或进行任何可观察的状态更改
• 在不使用结果的情况下调用它显然是一个错误，因为除非枚举序列，否则它没有任何作用，所以我希望Resharper在这样做时向我发出警告。

缺点：

• 即使Apply方法本身是纯方法，枚举结果序列也会使状态发生可观察的变化（这是方法的重点）。例如，items.Apply(i => i.Count++)将在每次枚举时更改项目的值。因此，应用Pure属性可能会误导...

你怎么看？是否应该应用该属性？

不，它不是纯净的，因为它有副作用。具体来说，它正在调用action每个项目。另外，它也不是线程安全的。

纯函数的主要特性是可以调用任意次，并且除了返回相同的值外，它不会做任何其他事情。这不是你的情况。同样，纯正意味着除了输入参数外，您不使用其他任何东西。这意味着可以随时从任何线程调用它，而不会引起任何意外行为。同样，您的功能也不是这种情况。

同样，您可能会误认为一件事：函数纯度不是优缺点的问题。即使是唯一的怀疑，即它可能有副作用，也足以使其不纯净。

埃里克·利珀特（Eric Lippert）提出了一个很好的观点。我将使用http://msdn.microsoft.com/zh-CN/library/dd264808(v=vs.110).aspx作为我的反论证的一部分。特别是线

允许使用纯方法修改进入纯方法后创建的对象。

可以说我们创建这样的方法：

int Count<T>(IEnumerable<T> e)
{
    var enumerator = e.GetEnumerator();
    int count = 0;
    while (enumerator.MoveNext()) count ++;
    return count;
}

首先，这也假设GetEnumerator是纯粹的（我真的找不到关于它的任何资料）。如果是，则根据上述规则，我们可以用[Pure]注释此方法，因为它仅修改在主体本身内部创建的实例。之后，我们可以组成和和ApplyIterator，这应该产生纯函数，对吗？

Count(ApplyIterator(source, action));

号这组合物不是纯的，甚至当两个Count和ApplyIterator是纯的。但是我可能在错误的前提下建立了这种观点。我认为，在方法中创建的实例不受纯度规则约束的想法是错误的，或者至少不够具体。

我不同意欣快和罗伯特·哈维的回答。绝对是纯函数；问题是

它只是在返回序列之前对序列的每个项目执行操作。

尚不清楚第一个“它”是什么意思。如果“它”表示这些功能之一，那是不正确的；这些功能都没有这样做；该MoveNext序列的枚举的这样做，而且“收益”通过的项目Current属性，而不是通过返回它。

这些序列是延迟枚举的，不是急切的，因此在序列返回之前肯定不采取行动Apply。如果在枚举器上调用，则在返回序列后应用该操作MoveNext。

如您所述，这些函数执行一个动作和一个序列，然后返回一个序列。输出取决于输入，并且不会产生副作用，因此这些都是纯函数。

现在，如果您创建结果序列的枚举器，然后在该迭代器上调用MoveNext，则MoveNext方法不是纯函数，因为它调用动作并产生副作用。但是我们已经知道MoveNext并不是纯粹的，因为它会变异枚举器！

现在，关于您的问题，您是否应该应用属性：我不会应用属性，因为我不会首先编写此方法。如果我想对序列应用动作，那么我写

foreach(var item in sequence) action(item);

这很清楚。

它不是纯函数，因此应用Pure属性会产生误导。

纯函数不会修改原始集合，并且您传递的动作是否无效都无关紧要。它仍然是一种不纯功能，因为其目的是引起副作用。

如果要使函数纯净，请将集合复制到新集合，将Action所做的更改应用于新集合，然后返回新集合，而使原始集合保持不变。

在我看来，它接收到一个Action（而不是PureAction之类的东西）的事实使其不纯净。

我什至不同意埃里克·利珀特。他写道：“（（）=> {}可转换为Action，它是一个纯函数。它的输出仅取决于其输入，并且没有明显的副作用”。

好吧，想象一下，而不是使用委托，ApplyIterator调用了一个名为Action的方法。

如果Action是纯函数，那么ApplyIterator也是纯函数。如果Action不纯净，则ApplyIterator不能纯净。

考虑到委托类型（不是实际的给定值），我们不能保证它将是纯净的，因此，仅当委托是纯净的时，该方法才能作为纯净方法使用。因此，要使其真正变得纯净，它应该接收一个纯净的委托（并且存在，我们可以将委托声明为[Pure]，这样我们就可以拥有PureAction）。

用不同的方式解释它，纯方法应该始终在相同的输入下给出相同的结果，并且不应产生可观察到的变化。可以为ApplyIterator提供相同的源和委托两次，但是，如果委托正在更改引用类型，则下一次执行将给出不同的结果。示例：委托执行类似item.Content + =“ Changed”的操作；

因此，在“字符串容器”（具有Content类型字符串属性的对象）列表上使用ApplyIterator，我们可能具有以下原始值：

Test

Test2

第一次执行后，列表将具有以下内容：

Test Changed

Test2 Changed

这是第三次：

Test Changed Changed

Test2 Changed Changed

因此，我们正在更改列表的内容，因为委托不是纯粹的，并且如果执行3次则无法优化避免执行3次调用，因为每次执行都会产生不同的结果。