tutorial - Diseño de lenguaje C#: grupo de métodos dentro del operador `es`

tipos de datos en c#

Question

Estoy interesado en algunas opciones de diseño de lenguaje C #. Hay una regla en la especificación de C # que permite usar grupos de métodos como las expresiones de is operador:

class Foo {
static void Main() { if (Main is Foo) Main(); }
}

La condición anterior siempre es falsa, como dice la especificación:

7.10.10 El operador es

• Si E es un grupo de métodos o el literal nulo, de si el tipo de E es un tipo de referencia o un tipo que acepta valores nulos y el valor de E es nulo, el resultado es falso.

Mis preguntas: ¿cuál es el propósito / punto / razón de permitir el uso del elemento de lenguaje C # sin representación en tiempo de ejecución en CLR, como los grupos de métodos dentro de dicho operador de "tiempo de ejecución"?

Answer 1

¿Cuál es el propósito / punto / razón de permitir el uso del elemento de lenguaje C # sin representación en tiempo de ejecución en CLR, como los grupos de métodos dentro de dicho operador de "tiempo de ejecución"?

El archivo de notas de diseño de idiomas no hace ninguna mención de por qué se tomó esta decisión, por lo que cualquier suposición de una respuesta será una conjetura. Mencionan que si el resultado del "es" puede determinarse estáticamente como siempre verdadero o falso, que así sea determinado y produzca una advertencia. Parece plausible que esto podría ser simplemente un error.

La razón más común para convertir lo que correctamente podría ser un error en una advertencia (o simplemente permitirlo) es porque disminuye la carga para los productores de programas que generan código automáticamente. Sin embargo, no veo un escenario realmente convincente aquí.

ACTUALIZAR:

Acabo de comprobar la especificación de C # 1.0. No tiene este lenguaje en ella. No dice nada sobre nulos o argumentos de grupos de métodos. Y, por supuesto, no dice nada acerca de las conversiones de grupos de métodos porque en C # 1.0 no hubo conversiones de grupos de métodos implícitas; tenías que llamar explícitamente "nueva D (M)" si querías convertir el método M para delegar el tipo D.

Este último punto es la justificación de que "M es D" devuelve falso en lugar de verdadero; No puedes decir legalmente "D d = M;" Entonces, ¿por qué debería ser verdad "M es D"?

Por supuesto, en C # 2.0 esto tiene menos sentido, ya que puedes decir "D d = M;" en C # 2.0.

También le pregunté a una de las personas presentes cuando se diseñó el operador "is" y no recordaba haber decidido nunca esta cuestión de una manera u otra. Su sospecha era que el diseño original del operador "is" era no dar ningún error, solo advertencias, y que todo el texto en la especificación sobre qué hacer con los grupos de métodos y los nulos y todo lo demás se agregó post-hoc, para el Versión C # 2.0 de la especificación, y en función de lo que realmente hizo el compilador.

En resumen, parece que este era un agujero de diseño en C # 1.0 que se tapó cuando se actualizó la especificación para C # 2.0. No parece que este comportamiento específico fuera deseado e implementado deliberadamente.

Esta teoría se ve reforzada por el hecho de que los métodos anónimos producen un error cuando se usan como un argumento para "es" en C # 2.0. No sería un cambio importante hacer eso, pero sería un cambio importante hacer que "M is D" comience a volver repentinamente verdadero o sea un error.

MÁS ACTUALIZACIÓN:

Mientras investigaba esto aprendí algo interesante. (Para mí). Cuando la característica se diseñó originalmente, el diseño debía permitir el nombre de un tipo o un objeto Tipo como el argumento de la mano derecha a "es". Sin embargo, esa idea se abandonó mucho antes de que se enviara C # 1.0.

Answer 2

En primer lugar, un método no es un tipo, msdn establece claramente lo siguiente:

El operador is usa para verificar si el tipo de tiempo de ejecución de un objeto es compatible con un tipo dado

Ejemplo

public static void Test (object o)
{
Class1 a;
if (o is Class1) {}
}

Desde MSDN:

Una expresión is se evalúa como verdadera si se cumplen las dos condiciones siguientes:

• expresión no es nula
• expresión se puede convertir para escribir. Es decir, una expresión de conversión del formulario (tipo) (expresión) se completará sin lanzar una excepción. Para obtener más información, consulte 7.6.6 Expresiones de conversión.

Entonces, la razón para que su ejemplo sea falso en el segundo punto, tiene que ser convertible en un tipo específico.

Espero no haber entendido mal la pregunta.