¿Por qué no hay inmutabilidad declarativa en C#?

Question

¿Por qué los diseñadores de C# no permitieron algo como esto?

public readonly class ImmutableThing 
{ 
    ... 
} 

Una de las formas más importantes para el seguro multi-threading es el uso de los objetos inmutables/clases, sin embargo, no hay manera de declarar una clase como inmutable. Sé que puedo hacer que sea inmutable mediante una implementación adecuada, pero hacer que la declaración de clase lo haga cumplir lo haría mucho más fácil y seguro. Comentar una clase como inmutable es, en el mejor de los casos, una solución de "soporte de puerta".

Una ojeada a una declaración de clase e inmediatamente sabría que era inmutable. Si tuviera que modificar el código de otra persona, sabría que una clase no permite cambios por intención. Solo puedo ver ventajas aquí, pero no puedo creer que nadie haya pensado en esto antes. Entonces, ¿por qué no es compatible?

EDITAR

Algunos dicen que esto no es una característica muy importante, pero que en realidad no me convence. Procesadores multinúcleo aparecieron porque el aumento del rendimiento por frecuencia golpeó una pared. Los supercomputadores son máquinas muy multiprocesador. El procesamiento en paralelo es cada vez más importante y es una de las principales formas de mejorar el rendimiento. El soporte para multihilo y procesamiento paralelo en .NET es significativo (varios tipos de bloqueo, grupo de subprocesos, tareas, llamadas asincrónicas, colecciones concurrentes, bloqueo de colecciones, foreach paralelo, PLINQ, etc.) y me parece todo lo que te ayuda a escribir paralelamente el código más fácilmente da una ventaja. Incluso si no es trivial de implementar.

Answer 1

Básicamente, porque es complicado, y como escribió el usuario, las funciones necesitan mucho trabajo de diversas maneras antes de que estén listas para enviar. (Es fácil ser un diseñador del lenguaje sillón - Estoy seguro de que es muy difícil de realmente hacerlo, en un idioma con millones de desarrolladores con bases de códigos críticos que no pueden romperse por los cambios.)

Es complicado para que un compilador verifique que un tipo sea visiblemente inmutable sin ser excesivamente restrictivo en algunos casos. Como ejemplo, String es realmente mutable dentro de mscorlib, pero el código de otros tipos (por ejemplo, StringBuilder) se ha escrito con mucho cuidado para evitar que el mundo exterior alguna vez vea esa mutabilidad.

Eric Lippert tiene written a lot on immutability - es un tema complejo que/se necesita una gran cantidad de trabajo para convertirse en una característica del lenguaje práctico. También es bastante difícil de actualizar en un lenguaje y framework que no lo tenía para empezar.Me encantaría C# para, al menos, hacer más fácil escribir tipos inmutables, y sospecho que el equipo ha pasado bastante tiempo pensando en ello, si alguna vez serán lo suficientemente felices con sus ideas para convertirlo en un lenguaje de producción característica es una cuestión diferente.

Answer 2

Las características deben diseñarse, implementarse, probarse, documentarse, implementarse y admitirse. Es por eso que obtenemos las características más importantes primero, y las menos importantes tarde o nunca.

Su propuesta está bien, pero hay una solución fácil (como usted dijo). Por lo tanto, no es una característica "urgente".

También hay una cosa llamada inmutabilidad representacional donde las mutaciones de estado dentro del objeto están permitidas pero nunca son visibles desde el exterior. Ejemplo: un campo calculado de forma lenta. Esto no sería posible en su propuesta porque el compilador nunca podría probar que la clase es inmutable al exterior, aunque su campo se escribe de forma rutinaria.