¿Es puro este método?

Tengo el siguiente método de extensión:

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

Simplemente aplica una acción a cada elemento de la secuencia antes de devolverlo.

Me preguntaba si debería aplicar el Pureatributo (de las anotaciones de Resharper) a este método, y puedo ver argumentos a favor y en contra.

Pros:

• estrictamente hablando, es puro; simplemente llamarlo en una secuencia no altera la secuencia (devuelve una nueva secuencia) ni realiza ningún cambio de estado observable
• llamarlo sin usar el resultado es claramente un error, ya que no tiene ningún efecto a menos que se enumere la secuencia, por lo que me gustaría que Resharper me avise si hago eso.

Contras:

• a pesar de que el Applymétodo en sí es puro, enumerar la secuencia resultante hará cambios de estado observables (que es el punto del método). Por ejemplo, items.Apply(i => i.Count++)cambiará los valores de los elementos cada vez que se enumeren. Entonces, aplicar el atributo Pure es probablemente engañoso ...

¿Qué piensas? ¿Debo aplicar el atributo o no?

No, no es puro, porque tiene efectos secundarios. Concretamente está llamando actiona cada elemento. Además, no es seguro para subprocesos.

La propiedad principal de las funciones puras es que se puede llamar cualquier número de veces y nunca hace nada más que devolver el mismo valor. Que no es tu caso. Además, ser puro significa que no usa nada más que los parámetros de entrada. Esto significa que se puede invocar desde cualquier subproceso en cualquier momento y no causar ningún comportamiento inesperado. De nuevo, ese no es el caso de su función.

Además, puede estar equivocado en una cosa: la pureza de la función no es una cuestión de pros o contras. Incluso una sola duda, que puede tener efectos secundarios, es suficiente para que no sea pura.

Eric Lippert plantea un buen punto. Voy a usar http://msdn.microsoft.com/en-us/library/dd264808(v=vs.110).aspx como parte de mi contraargumento. Especialmente linea

Un método puro puede modificar los objetos que se han creado después de ingresar al método puro.

Digamos que creamos un método como este:

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

Primero, esto supone que también GetEnumeratores puro (realmente no puedo encontrar ninguna fuente sobre eso). Si es así, de acuerdo con la regla anterior, podemos anotar este método con [Puro], porque solo modifica la instancia que se creó dentro del propio cuerpo. Después de eso podemos componer esto y el ApplyIterator, lo que debería resultar en una función pura, ¿verdad?

Count(ApplyIterator(source, action));

No. Esta composición no es pura, incluso cuando ambas County ApplyIteratorson puras. Pero podría estar construyendo este argumento sobre premisas equivocadas. Creo que la idea de que las instancias creadas dentro del método están exentas de la regla de pureza es incorrecta o al menos no lo suficientemente específica.

No estoy de acuerdo con las respuestas de Euphoric y Robert Harvey . Absolutamente esa es una función pura; el problema es ese

Simplemente aplica una acción a cada elemento de la secuencia antes de devolverlo.

No está muy claro qué significa el primer "eso". Si "eso" significa una de esas funciones, entonces eso no está bien; ninguna de esas funciones hace eso; el MoveNextdel enumerador de la secuencia hace eso y "devuelve" el elemento a través de la Currentpropiedad, no devolviéndolo.

Esas secuencias se enumeran perezosamente , no con entusiasmo, por lo que ciertamente no es el caso que la acción se aplique antes de que la secuencia sea devuelta por Apply. La acción se aplica después de que se devuelve la secuencia, si MoveNextse llama en un enumerador.

Como observa, estas funciones toman una acción y una secuencia y devuelven una secuencia; la salida depende de la entrada y no se producen efectos secundarios, por lo que estas son funciones puras.

Ahora, si crea un enumerador de la secuencia resultante y luego llama a MoveNext en ese iterador, entonces el método MoveNext no es puro, porque llama a la acción y produce un efecto secundario. ¡Pero ya sabíamos que MoveNext no era puro porque muta el enumerador!

Ahora, en cuanto a su pregunta, si aplica el atributo: no aplicaría el atributo porque no escribiría este método en primer lugar . Si quiero aplicar una acción a una secuencia, entonces escribo

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

Que está muy bien claro.

No es una función pura, por lo que aplicar el atributo Pure es engañoso.

Las funciones puras no modifican la colección original, y no importa si está pasando una acción que no tiene efecto o no; sigue siendo una función impura porque su intención es causar efectos secundarios.

Si desea que la función sea pura, copie la colección a una nueva colección, aplique los cambios que la Acción realiza a la nueva colección y devuelva la nueva colección, dejando la colección original sin cambios.

En mi opinión, el hecho de que reciba una Acción (y no algo así como PureAction) hace que no sea pura.

E incluso estoy en desacuerdo con Eric Lippert. Escribió que "() => {} es convertible a Acción, y es una función pura. Sus salidas dependen únicamente de sus entradas y no tiene efectos secundarios observables".

Bueno, imagine que en lugar de usar un delegado, ApplyIterator invoca un método llamado Acción.

Si Action es puro, entonces ApplyIterator también es puro. Si Action no es puro, entonces ApplyIterator no puede ser puro.

Teniendo en cuenta el tipo de delegado (no el valor dado real), no tenemos la garantía de que sea puro, por lo que el método se comportará como un método puro solo cuando el delegado sea puro. Entonces, para hacerlo realmente puro, debe recibir un delegado puro (y eso existe, podemos declarar un delegado como [Puro], para que podamos tener una PureAction).

Explicando de manera diferente, un método Pure siempre debe dar el mismo resultado con las mismas entradas y no debe generar cambios observables. ApplyIterator puede recibir la misma fuente y delegar dos veces pero, si el delegado está cambiando un tipo de referencia, la próxima ejecución dará resultados diferentes. Ejemplo: el delegado hace algo como item.Content + = "Modificado";

Entonces, usando el ApplyIterator sobre una lista de "contenedores de cadenas" (un objeto con una propiedad Content de tipo string), podemos tener estos valores originales:

Test

Test2

Después de la primera ejecución, la lista tendrá esto:

Test Changed

Test2 Changed

Y esta la tercera vez:

Test Changed Changed

Test2 Changed Changed

Por lo tanto, estamos cambiando el contenido de la lista porque el delegado no es puro y no se puede hacer una optimización para evitar ejecutar la llamada 3 veces si se invoca 3 veces, ya que cada ejecución generará un resultado diferente.