En respuesta a mi otra respuesta, Eric Smith señala correctamente:
"... porque requeriría implícitamente boxeo el parámetro de tipo receptor ...". Que es lo que sucede de todos modos, si haces algo como esto: Func f = 5.ToString; Lo cual es perfectamente legal.
Pensar en esto me ha llevado a una nueva respuesta. Pruebe esto para el tamaño:
Los métodos ordinarios de "instancia" en las estructuras toman, en el nivel CIL, un "puntero administrado" (tipo &
) como un parámetro de receptor. Esto es necesario para que los métodos de instancia en las estructuras puedan asignar a los campos de la estructura. Ver Partition II, Section 13.3.
De forma similar, los métodos de instancia en clases toman una "referencia de objeto" (tipo O
) como un parámetro de receptor (la diferencia es que este es un puntero al montón administrado, y necesita ser rastreado para GC).
Dado que tanto CIL &
como O
se pueden implementar (y se implementan) mediante punteros, todo es genial para la implementación del delegado. Independientemente de si un delegado captura un método estático, un método de instancia de clase o un método de instancia de estructura, todo lo que necesita hacer es pasar el puntero a su _target
al primer argumento de la función.
Pero el escenario que estamos discutiendo arruina eso. Un método de extensión estático tomando un int
como primer argumento requiere un argumento CIL de tipo int32
(ver Partición III, sección 1.1.1). Aquí es donde las cosas se descarrilan. No veo ninguna razón por la cual no sería posible para la implementación de delegados para darse cuenta de que esto estaba sucediendo (por ejemplo, inspeccionando los metadatos asociados con el MethodInfo que se está capturando) y emitir un procesador que unbox el _target
y lo pasa como el primer argumento, pero esto no es necesario para los delegados a métodos de instancia clásicos en structs, ya que esperan un puntero de todos modos y no aparece (a juzgar por el ejemplo en mi respuesta incorrecta anterior) a ser implementado. Obviamente, el tipo de valor específico en cuestión controlaría la naturaleza exacta del procesador requerido.
A menos que me falta un obstáculo más fundamental para la implementación (podría imaginar que podría plantear problemas para el verificador, por ejemplo), parece que se podría hacer un caso razonable para extender el tiempo de ejecución para apoyar este caso, pero todos los signos apuntan a que esto es una limitación del tiempo de ejecución y no del compilador C# per se.
¿Estás seguro de que no es CS1113? –
Es; fijo. Gracias – SLaks