c# - f# codes

¿Incluye C(o lo hará) características para la verificación de efectos secundarios?

Question

Sé que C # está recibiendo una gran cantidad de soporte de programación en paralelo, pero AFAIK todavía no hay construcciones para la verificación de efectos secundarios, ¿verdad?

Supongo que es más complicado ahora que C # ya está diseñado. ¿Pero hay planes para lograr esto? ¿O es F # el único lenguaje .NET que tiene construcciones para la verificación de efectos secundarios?

Answer 1

C # el lenguaje no es, pero .NET puede ser el marco.

La biblioteca Contracts + las herramientas de análisis estático que se están introduciendo en .NET 4 podrían presentarlas:

Microsoft está utilizando [Inmutable] y [Pure] dentro de .NET 3.5 framework en este momento.

Por ejemplo, vea [Microsoft.Contracts.Immutable] y [Microsoft.Contracts.Pure] dentro de .NET 3.5, en System.Core.dll. Lamentablemente, son internos. Sin embargo, Microsoft.Contracts. * Proviene principalmente de la investigación de Spec #, y Spec # se ha incluido en las API de contratos que formarán parte de .NET 4.0.

Veremos qué viene de esto. No he comprobado si los bits .NET 4.0 previos a la publicación contienen alguna API como [Pure] o [Inmutable] en las API de contratos. Si lo hacen, me imagino que la herramienta de análisis estático será la que aplicará la regla en lugar del compilador.

editar Acabo de cargar Microsoft.Contracts.dll desde la última versión preliminar de MS Code Contracts esta semana. Buenas noticias: los atributos [Pure] y [Mutability (Mutability.Immutable)] existen en la biblioteca, lo que sugiere que estarán en .NET 4.0. Woohoo!

editar 2 Ahora que se lanzó .NET 4, busqué estos tipos. [Pure] todavía está allí en System.Diagnostics.Contracts namespace. No está destinado para uso general, sino para su uso con la verificación previa y posterior a la condición de la API de contrato. No se aplica el compilador, tampoco la herramienta de verificación del contrato de código impone la pureza . [Mutability] se ha ido. Curiosamente, cuando Microsoft estaba usando los atributos de Mutability y Pure en .NET 3.5 (en la clase interna de BigInteger en System.Core.dll), .NET 4 ha movido BigInteger a System.Numerics, y ha eliminado el [Pure] y [Mutability] atributos de ese tipo. En pocas palabras: parece que .NET 4 no hace nada para la verificación de efectos secundarios.

editar 3 Con las recientes herramientas de compilación como servicio de Microsoft Rosyln recientemente (finales de 2011), que se cree que están programadas para RTM en Visual Studio 2015, parece que podrán soportar cosas como esta; podría escribir extensiones al compilador para verificar la pureza e inmutabilidad, y emitir advertencias del compilador si algo decorado con esos atributos no sigue las reglas. Aun así, estamos buscando algunos años para apoyar esto.

editar 4 Ahora que Rosyln está aquí a partir del verano de 2015, existe la capacidad de crear una extensión de compilación para pure / inmutability. Sin embargo, eso no hace nada por el código de framework existente, ni el código de biblioteca de terceros. Pero en el horizonte hay una propuesta de C # 7 para tipos inmutables . Esto sería impuesto por el compilador e introduciría una nueva palabra clave inmutable para C # y un atributo [Inmutable] en .NET framework. Uso:

// Edit #4: This is a proposed design for C# 7 immutable as of June 2015.
// Compiler will implicitly mark all fields as readonly.
// Compiler will enforce all fields must be immutable types.
public immutable class Person
{
public Person(string firstName, string lastName, DateTimeOffset birthDay)
{
FirstName = firstName; // Properties can be assigned only in the constructor.
LastName = lastName;
BirthDay = birthDay;
}
public string FirstName { get; } // String is [Immutable], so OK to have as a readonly property
public string LastName { get; }
public DateTime BirthDay { get; } // Date is [Immutable] too.
}

editar 5 Es noviembre de 2016, y parece que los tipos inmutables se eliminaron de C # 7. Siempre hay esperanza para C # 8. :-)

edit 6 Es noviembre de 2017. C # 8 está saliendo a la vista, y aunque no tendremos funciones puras, tendremos estructuras de solo lectura . Esto hace que una estructura sea inmutable, lo que permite varias optimizaciones del compilador.

Answer 2

En principio, es fácil verificar si algo es inmutable y si el código carece de efectos secundarios. Todos los campos de la estructura de clase / datos deben ser de solo lectura y su tipo debe ser otro objeto inmutable. También necesitaríamos una forma de marcar a un delegado como "puro" (sin efectos secundarios), pero probablemente todo sea posible.

Sin embargo, el problema es que esto a menudo es demasiado restrictivo. En F #, generalmente escribirías el código con un estilo libre de efectos laterales e inmutable, pero a menudo es beneficioso usar alguna mutación localmente. Esto no rompe la pureza general (en cierto sentido) y hace que sea mucho más fácil escribir el código. Sin embargo, verificar esto automáticamente es difícil (significa que es un problema teórico interesante ...)

Por ejemplo, está perfectamente bien trabajar con matrices de forma "pura". Puede tener métodos como Array.map que apliquen alguna función a todos los elementos y devuelvan una nueva matriz sin modificar la original. La función muta la matriz (recién creada) antes de devolverla, pero la matriz no está mutada en ningún otro lugar, por lo que en principio es pura , pero difícil de verificar (y este es un patrón de programación bastante útil en F #).

Por lo tanto, creo que se puede hacer mucho, pero la simple prohibición de todos los efectos secundarios puede no ser tan buena como parece. Lo bueno de los contratos es que también podrían usarse en este escenario.

Answer 3

No solo no hay nada para la verificación de los efectos secundarios: no hay nada ni siquiera para verificar que un tipo sea inmutable, que es un paso más pequeño a lo largo de la misma ruta de IMO.

No creo que haya nada en el C # 4.0 (aunque fácilmente podría estar equivocado). Realmente espero que la inmutabilidad tenga un impacto en C # 5.0; Ciertamente Eric Lippert ha blogueado bastante al respecto, y la gente de MS ha estado pensando en el paralelismo en una cantidad justa.

Lo siento, no es una imagen más alentadora.

Edit: la respuesta de Judah es considerablemente más brillante ... ¿el soporte de framework sería lo suficientemente bueno para ti? :) (No me sorprendería del todo que algunos aspectos de los Contratos de Código no estuvieran listos para .NET 4.0, fíjate si quizás mantuvieron el lanzamiento inicial relativamente pequeño y lo impulsaron más tarde).