Este método é puro?

Eu tenho o seguinte método de extensão:

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

Apenas aplica uma ação a cada item da sequência antes de devolvê-lo.

Eu queria saber se eu deveria aplicar o Pureatributo (das anotações do Resharper) a esse método, e posso ver argumentos a favor e contra.

Prós:

• estritamente falando, é puro; apenas chamá-lo em uma sequência não altera a sequência (retorna uma nova sequência) ou faz qualquer alteração de estado observável
• chamá-lo sem usar o resultado é claramente um erro, pois não tem efeito, a menos que a sequência seja enumerada, portanto, gostaria que o Resharper me avisasse se eu fizer isso.

Contras:

• mesmo que o Applymétodo em si seja puro, enumerar a sequência resultante fará alterações de estado observáveis ​​(que é o ponto do método). Por exemplo, items.Apply(i => i.Count++)alterará os valores dos itens toda vez que forem enumerados. Portanto, a aplicação do atributo Pure é provavelmente enganosa ...

O que você acha? Devo aplicar o atributo ou não?

Não, não é puro, porque tem efeito colateral. Concretamente, está chamando actioncada item. Além disso, não é seguro para threads.

A principal propriedade das funções puras é que ela pode ser chamada inúmeras vezes e nunca faz nada além de retornar o mesmo valor. Qual não é o seu caso? Além disso, ser puro significa que você não usa nada além dos parâmetros de entrada. Isso significa que pode ser chamado de qualquer thread a qualquer momento e não causar nenhum comportamento inesperado. Novamente, esse não é o caso de sua função.

Além disso, você pode estar enganado em uma coisa: a pureza da função não é uma questão de prós ou contras. Mesmo uma única dúvida, que pode ter efeito colateral, é suficiente para torná-lo não puro.

Eric Lippert levanta um bom ponto. Vou usar http://msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx como parte do meu contra-argumento. Especialmente linha

Um método puro pode modificar objetos que foram criados após a entrada no método puro.

Vamos dizer que criamos um método como este:

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

Primeiro, isso pressupõe que isso GetEnumeratoré puro também (eu realmente não consigo encontrar nenhuma fonte nisso). Se for, de acordo com a regra acima, podemos anotar esse método com [Pure], porque ele modifica apenas a instância que foi criada dentro do próprio corpo. Depois disso, podemos compor isso e o ApplyIterator, o que deve resultar em pura função, certo?

Count(ApplyIterator(source, action));

Não. Esta composição não é pura, mesmo quando ambos Counte ApplyIteratorsão puros. Mas eu posso estar construindo esse argumento com premissa errada. Penso que a ideia de que instâncias criadas dentro do método estão isentas da regra de pureza está errada ou, pelo menos, não é específica o suficiente.

Não concordo com as respostas de Eufórico e de Robert Harvey . Absolutamente essa é uma função pura; o problema é que

Apenas aplica uma ação a cada item da sequência antes de devolvê-lo.

não está muito claro o que significa o primeiro "isso". Se "it" significa uma dessas funções, isso não está certo; nenhuma dessas funções faz isso; o MoveNextdo enumerador da sequência faz isso e "retorna" o item por meio da Currentpropriedade, não retornando.

Essas seqüências são enumeradas preguiçosamente , não com muita ansiedade, portanto, certamente não é o caso de a ação ser aplicada antes que a sequência seja retornada Apply. A ação é aplicada após o retorno da sequência, se MoveNextfor chamada em um enumerador.

Como você observa, essas funções executam uma ação e uma sequência e retornam uma sequência; a saída depende da entrada e nenhum efeito colateral é produzido; portanto, são funções puras.

Agora, se você criar um enumerador da sequência resultante e chamar MoveNext nesse iterador, o método MoveNext não será puro, porque chama a ação e produz um efeito colateral. Mas já sabíamos que o MoveNext não era puro porque modifica o enumerador!

Agora, quanto à sua pergunta, você deve aplicar o atributo: Eu não aplicaria o atributo porque não escreveria esse método em primeiro lugar . Se eu quiser aplicar uma ação a uma sequência, escrevo

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

o que é bem claro.

Não é uma função pura, portanto, a aplicação do atributo Pure é enganosa.

As funções puras não modificam a coleção original e não importa se você está passando uma ação que não tem efeito ou não; ainda é uma função impura porque sua intenção é causar efeitos colaterais.

Se você deseja tornar a função pura, copie a coleção para uma nova coleção, aplique as alterações que a Ação realiza na nova coleção e retorne a nova coleção, mantendo a coleção original inalterada.

Na minha opinião, o fato de receber uma ação (e não algo como PureAction) não a torna pura.

E eu até discordo de Eric Lippert. Ele escreveu que "() => {} é conversível em Ação, e é uma função pura. Suas saídas dependem apenas de suas entradas e não têm efeitos colaterais observáveis".

Bem, imagine que, em vez de usar um delegado, o ApplyIterator estivesse invocando um método chamado Action.

Se Ação for pura, o ApplyIterator também será puro. Se a Ação não for pura, o ApplyIterator não poderá ser puro.

Considerando o tipo de delegado (não o valor real fornecido), não temos a garantia de que seja puro; portanto, o método se comportará como um método puro somente quando o delegado for puro. Portanto, para torná-lo realmente puro, ele deve receber um delegado puro (e isso existe, podemos declarar um delegado como [Puro], para que possamos ter um PureAction).

Explicando de maneira diferente, um método Pure sempre deve fornecer o mesmo resultado, com as mesmas entradas e não deve gerar mudanças observáveis. O ApplyIterator pode receber a mesma fonte e delegar duas vezes, mas, se o delegado estiver alterando um tipo de referência, a próxima execução fornecerá resultados diferentes. Exemplo: O delegado faz algo como item.Content + = "Changed";

Portanto, usando o ApplyIterator sobre uma lista de "contêineres de strings" (um objeto com uma propriedade Content do tipo string), podemos ter estes valores originais:

Test

Test2

Após a primeira execução, a lista terá o seguinte:

Test Changed

Test2 Changed

E é a terceira vez:

Test Changed Changed

Test2 Changed Changed

Portanto, estamos alterando o conteúdo da lista porque o delegado não é puro e nenhuma otimização pode ser feita para evitar a execução da chamada 3 vezes se invocada 3 vezes, pois cada execução gera um resultado diferente.