Hace (o será) C # incluir características para la verificación de los efectos secundarios?

Question

Yo sé C # está recibiendo mucho apoyo programación paralela, pero que yo sepa todavía no hay una constructos para la verificación de los efectos secundarios, ¿verdad?

Asumo que es más difícil ahora que C # ya está diseñada. Pero ¿hay planes para conseguir esto en? O es F # el único lenguaje .NET que tiene construcciones para la verificación de los efectos secundarios?

Answer 1

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

La biblioteca contratos + las herramientas de análisis estático se introducen en .NET 4 podría introducir estos:

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

Por ejemplo, ver [Microsoft.Contracts.Immutable] y [Microsoft.Contracts.Pure] dentro de .NET 3.5, en el System.Core.dll. Por desgracia, son internos. Sin embargo, Microsoft.Contracts. * Está en su mayoría nacen de Spec # investigación y Spec # se ha doblado en los APIs de contratos que serán parte de .NET 4.0.

Vamos a ver qué sale de esto. No he comprobado para ver si el pre-lanzamiento de .NET 4.0 bits contienen ninguna API como [puro] o [Inmutable] en el API contratos. Si lo hacen, me imagino la herramienta de análisis estático será el de hacer cumplir la regla, más que el compilador.

editar Me acaba de cargar hasta Microsoft.Contracts.dll de la última gota de pre-lanzamiento de los contratos MS Código esta semana. Buenas noticias: [puro] y [mutabilidad (Mutability.Immutable)] existen atributos en la biblioteca, lo que sugiere que estarán en .NET 4.0. Woohoo!

editar 2 Ahora que .NET 4 ha sido puesto en libertad, busqué estos tipos. [Pure] todavía está allí en System.Diagnostics.Contracts espacio de nombres. No es la intención de uso general, sino más bien, para su uso con la comprobación previa y posterior a la condición de la API de contrato. No se aplica compilador, tampoco lo hace la herramienta de comprobación Código Contrato hacer cumplir la pureza . [Mutabilidad] se ha ido. Curiosamente, en el que Microsoft estaba usando mutabilidad y atributos puros en .NET 3.5 (en la clase BigInteger interna en System.Core.dll), .NET 4 se ha movido en BigInteger System.Numerics, y se ha despojado a la [puro] y [Mutabilidad] atributos de ese tipo. En pocas palabras:. Aparece .NET 4 no hace nada para la verificación de los efectos secundarios

editar 3 Con la recientemente (finales de 2011) vista previa de Microsoft Rosyln compilador-as-a-service herramientas - que se cree para ser programado para RTM de Visual Studio 2015 - ver como van a estar capaz de soportar este tipo de cosas; se podría escribir extensiones para el compilador para comprobar la pureza y la inmutabilidad, y emitir advertencias del compilador si algo decorado con esos atributos no siguen las reglas. Aún así, estamos buscando a unos pocos años fuera para apoyar esto.

editar 4 Ahora que está aquí Rosyln partir del verano de 2015, la capacidad de construir una extensión para el compilador puro / inmutabilidad existe de hecho. Sin embargo, eso no hace nada por código marco existente, ni tercera parte código de la biblioteca. Pero en el horizonte es un C # 7 propuesta de tipos inmutables . Esto se aplica por el compilador y introduciría una nueva inmutable palabra clave para C # y un atributo [Inmutable] en el marco .NET. 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 estamos en noviembre de 2016, y parece tipos inmutables se dejaron caer desde C # 7. Siempre hay esperanza para C # 8.: -)

editar 6 de noviembre de 2017. C # 8 está llegando a plena vista, y si bien no vamos a tener funciones puras, que tendrá estructuras de sólo lectura . Esto hace que una estructura inmutable, lo que permite varias optimizaciones del compilador.

Answer 2

No sólo no hay nada para la verificación de efectos secundarios - no hay nada ni siquiera para comprobar que un tipo es inmutable, que es un paso más pequeño a lo largo de la misma ruta OMI

.

No creo que haya nada que baja la tubería en C # 4.0 (aunque podría fácilmente ser malo). Realmente esperanza que la inmutabilidad tiene un impacto en C # 5.0; Ciertamente Eric Lippert ha blogueado un poco acerca de ella, y gente de la EM ha estado pensando en una buena cantidad de paralelismo.

En este momento no es un panorama más alentador.

Editar: de Judah respuesta es considerablemente más brillante ... apoyaría marco ser lo suficientemente bueno para usted? :) (no sería del todo sorprendido si algunos aspectos de los contratos de código no estaban listos para .NET 4.0, que conste - si de alguna manera mantuvo la versión inicial relativamente pequeña y aumentó más tarde.)

Answer 3

En principio, verificar si algo es inmutable y si el código carece de efectos secundarios es fácil. Todos los campos de la estructura de clases / datos deben ser de sólo lectura y de qué tipo deben ser otro objeto inmutable. También nos necesitamos una forma para marcar un delegado como "pura" (libre de efectos secundarios), pero eso sería probablemente todo sea posible.

Sin embargo, el problema es que a menudo es demasiado restrictiva. En F #, usted generalmente escribir el código en un estilo libre y inmutable efecto secundario, pero a menudo es beneficioso utilizar alguna mutación a nivel local. Esto no rompe la pureza global (en algún sentido) y hace que sea mucho más fácil de escribir el código. Sin embargo, la verificación de esto automáticamente es difícil (meanin que es un problema teórico interesante ..)

Por ejemplo, es perfectamente posible trabajar con matrices de forma "pura". Usted puede tener métodos como Array.map que se aplica alguna función a todos los elementos y volver a nueva array sin modificar el original. La función muta la matriz (de nueva creación) antes de devolverlo, pero la matriz no está mutado en otro sitio, así que esto es, en principio, pura , pero es difícil de verificar (y este es el patrón de programación muy útil en F #).

Por lo tanto, creo que hay mucho que se podía hacer, sino simplemente la prohibición de todos los efectos secundarios pueden no ser tan buena forma, ya que parece ser. Lo bueno de los contratos es que podrían ser utilizadas probablemente en este escenario también.