¿Por qué 'void' no está permitido como un tipo genérico en C #?

¿Cuáles fueron las decisiones de diseño que argumentaron a favor de voidno ser construible y no ser permitido como un tipo genérico? Después de todo, es solo un vacío especial structy habría evitado la PITA total de tener distintos Funcy Actiondelegados.

(C ++ permite voiddevoluciones explícitas y permite voidcomo parámetro de plantilla)

El problema fundamental con "vacío" es que no significa lo mismo que cualquier otro tipo de retorno. "vacío" significa "si este método regresa, entonces no devuelve ningún valor". No nulo; nulo es un valor. No devuelve ningún valor en absoluto.

Esto realmente arruina el sistema de tipos. Un sistema de tipos es esencialmente un sistema para hacer deducciones lógicas sobre qué operaciones son válidas en valores particulares; un método de devolución nulo no devuelve un valor, por lo que la pregunta "¿qué operaciones son válidas en esta cosa?" no tiene ningún sentido en absoluto. No hay "cosa" para que haya una operación, válida o inválida.

Además, esto arruina el tiempo de ejecución algo feroz. El tiempo de ejecución .NET es una implementación del Sistema de ejecución virtual, que se especifica como una máquina de pila. Es decir, una máquina virtual donde todas las operaciones se caracterizan en términos de su efecto en una pila de evaluación. (Por supuesto, en la práctica, la máquina se implementará en una máquina con pila y registros, pero el sistema de ejecución virtual solo supone una pila). El efecto de una llamada a un método vacío es fundamentalmentediferente al efecto de una llamada a un método no nulo; Un método no nulo siempre pone algo en la pila, que puede ser necesario quitar. Un método nulo nunca pone algo en la pila. Y, por lo tanto, el compilador no puede tratar los métodos nulos y no nulos de la misma manera en el caso en que se ignora el valor devuelto del método; Si el método es nulo, no hay valor de retorno, por lo que no debe haber pop.

Por todas estas razones, "vacío" no es un tipo que pueda ser instanciado; no tiene valores , de eso se trata. ¡No es convertible en objeto, y un método de retorno nulo nunca puede tratarse polimórficamente con un método de retorno nulo porque hacerlo corrompe la pila!

Por lo tanto, void no se puede usar como argumento de tipo, lo cual es una pena, como se observa. Sería muy conveniente

Con el beneficio de la retrospectiva, hubiera sido mejor para todos los interesados ​​si, en lugar de nada, un método de retorno de vacío devolviera automáticamente "Unidad", un tipo de referencia de un solo objeto mágico. Entonces sabría que cada llamada a un método pone algo en la pila , sabrá que cada llamada a un método devuelve algo que podría asignarse a una variable de tipo de objeto y, por supuesto, la Unidad podría usarse como un argumento de tipo , por lo que habría no es necesario tener tipos de delegado Action y Func separados. Lamentablemente, ese no es el mundo en el que estamos.

Para algunos pensamientos más en este sentido, ver:

• http://blogs.msdn.com/b/ericlippert/archive/2009/06/29/the-void-is-invariant.aspx
• http://blogs.msdn.com/b/ericlippert/archive/2011/02/21/never-say-never-part-one.aspx
• http://blogs.msdn.com/b/ericlippert/archive/2011/11/28/why-have-a-stack.aspx

De: http://connect.microsoft.com/VisualStudio/feedback/details/94226/allow-void-to-be-parameter-of-generic-class-if-not-in-c-then-just-in- tiempo de ejecución

Esto es en realidad por diseño: no permitimos ninguna instancia del tipo vacío (junto con muchos otros tipos en el tiempo de ejecución). Tampoco puede crear un vacío vacío o vacío []. Conectamos estos agujeros tipo por seguridad.

Por mi vida no puedo ver cuán vacío es un agujero de seguridad, pero ... eso dice.