この方法は純粋ですか？

次の拡張メソッドがあります。

    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/en-us/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が純粋であっても、純粋ではありません。しかし、私はこの議論を間違った前提で構築しているのかもしれません。メソッド内で作成されたインスタンスが純正ルールから除外されるという考えは間違っているか、少なくとも十分に具体的ではないと思います。

EuphoricとRobert Harveyの両方の答えには同意しません。もちろん、それは純粋な関数です。問題はそれです

シーケンスの各アイテムにアクションを適用してから、それを返します。

最初の「それ」が何を意味するかは非常に不明確です。「それ」がそれらの機能の1つを意味する場合、それは正しくありません。これらの関数はどちらもそれを行いません。MoveNextシーケンスの列挙子のは、それを行う、とビアその「リターン」の項目Currentプロパティではなく、それを返すこと。

これらのシーケンスは、熱心にではなく遅延的に列挙されるため、シーケンスがによって返される前にアクションが適用されることは確かにありません。列挙子で呼び出された場合、アクションはシーケンスが返された後に適用されます。ApplyMoveNext

お気づきのように、これらの関数はアクションとシーケンスを実行し、シーケンスを返します。出力は入力に依存し、副作用は発生しないため、これらは純粋な関数です。

ここで、結果のシーケンスの列挙子を作成してから、そのイテレーターでMoveNextを呼び出すと、アクションを呼び出して副作用が生じるため、MoveNextメソッドは純粋ではありません。しかし、MoveNextは列挙子を変更するため、純粋ではないことはすでにわかっていました。

さて、あなたの質問に関して、あなたは属性を適用するべきですか？私は最初にこのメソッドを書かないので属性を適用しません。シーケンスにアクションを適用したい場合は、

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

それは明確です。

これは純粋な関数ではないため、Pure属性を適用すると誤解を招きます。

純粋な関数は元のコレクションを変更せず、影響のないアクションを渡すかどうかは関係ありません。その意図は副作用を引き起こすことなので、それはまだ不純な機能です。

関数を純粋にする場合は、コレクションを新しいコレクションにコピーし、アクションが取る変更を新しいコレクションに適用し、元のコレクションを変更せずに新しいコレクションを返します。

私の意見では、アクションを受け取る（PureActionのようなものではない）という事実は、純粋ではありません。

そして、私はエリック・リッパートにさえ同意しません。彼は、「（）=> {}はアクションに変換可能であり、純粋な関数です。出力は入力にのみ依存し、目に見える副作用はありません」と書いています。

デリゲートを使用する代わりに、ApplyIteratorがActionという名前のメソッドを呼び出していたとしましょう。

Actionが純粋な場合、ApplyIteratorも純粋です。Actionが純粋でない場合、ApplyIteratorを純粋にすることはできません。

デリゲートタイプ（実際の指定値ではない）を考慮すると、それが純粋であるという保証はありません。そのため、メソッドは、デリゲートが純粋である場合にのみ、純粋メソッドとして動作します。したがって、本当に純粋にするためには、純粋なデリゲートを受け取る必要があります（存在する場合、デリゲートを[Pure]として宣言できるため、PureActionを使用できます）。

異なる方法で説明すると、Pureメソッドは、同じ入力を与えられた場合、常に同じ結果を与えるはずであり、観察可能な変化を生成するべきではありません。ApplyIteratorには同じソースとデリゲートを2回指定できますが、デリゲートが参照タイプを変更している場合、次の実行では異なる結果が得られます。例：デリゲートはitem.Content + = "Changed";のようなことをします。

したがって、「文字列コンテナ」（文字列型のContentプロパティを持つオブジェクト）のリストに対してApplyIteratorを使用すると、次のような元の値が得られます。

Test

Test2

最初の実行後、リストは次のようになります。

Test Changed

Test2 Changed

そしてこれは3回目です：

Test Changed Changed

Test2 Changed Changed

したがって、リストの内容を変更しています。デリゲートは純粋ではなく、3回呼び出された場合に呼び出しが3回実行されるのを回避するための最適化を行うことができないためです。実行ごとに異なる結果が生成されるためです。