Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

17 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
martes, 26 de octubre de 2021
.NET Core Hoy va un post rapidito sobre un curioso detalle sintáctico de C# que me llamó la atención hace algún tiempo, mientras leía el artículo How to Stress the C# Compiler, donde Henning Dieterichs comenta varias formas de estresar (¡literalmente!) al compilador de C# utilizando construcciones admitidas por el lenguaje.

La cuestión es: ¿por qué no compila el siguiente código?
class Program {
    public static void Main() {
        int f = 0; int x = 0; int y = 0;
        System.Console.WriteLine(
            "{0} {1}",
            f < x,   // is f smaller than x?
            y > (-1) // is y greater than -1?
        );
    }
}

¡No sigáis leyendo! Echad un vistazo al código e intentad averiguarlo antes de ver la solución :)
He de decir que los comentarios "//" en el código contribuyen significativamente al despiste, pero la respuesta es bastante sencilla. Basta con eliminar ruido y reformatear un poco el código para verlo más claro:
class Program {
    public static void Main() {
        int f = 0; int x = 0; int y = 0;
        System.Console.WriteLine(
            "{0} {1}",
            f<x,y>(-1)
        );
    }
}
De esta forma, llegamos rápido a la conclusión de que el código conflictivo f<x,y>(-1) es sintácticamente correcto desde dos puntos de vista muy diferentes:
  • Dos parámetros suministrados a Console.WriteLine(), escritos como expresiones condicionales independientes:
    • f < x
    • y > (-1)
  • Una llamada a un método genérico f<x,y>, suministrándole el valor -1.
Ante este caso, durante el parseo Roslyn da prioridad a la segunda interpretación, por lo que el fallo en compilación es inevitable al no existir un método genérico f<x,y>() (bueno, y de hecho ni siquiera x e y son tipos, sino variables).

Curioso, ¿verdad?

Publicado en Variable not found.

3 Comentarios:

MontyCLT dijo...

Es curioso cuanto menos, sin embargo, me gustaría saber si hay más literatura sobre que regla sigue el compilador para dar prioridad a la segunda interpretación.

¡Un saludo!

José María Aguilar dijo...

Hola!

Pues si la hay, no la conozco :-/ Pero supongo que, con tiempo y paciencia, aquí se podrá ver algo:
LanguageParser.cs.

Saludos!

Unknown dijo...

Muy curioso!
Habrá que usar paréntesis