Roslyn no pudo compilar el código

Después de haber migrado mi proyecto de VS2013 a VS2015, el proyecto ya no se compila. Se produce un error de compilación en la siguiente declaración LINQ:

static void Main(string[] args)
{
    decimal a, b;
    IEnumerable<dynamic> array = new string[] { "10", "20", "30" };
    var result = (from v in array
                  where decimal.TryParse(v, out a) && decimal.TryParse("15", out b) && a <= b // Error here
                  orderby decimal.Parse(v)
                  select v).ToArray();
}

El compilador devuelve un error:

Error CS0165 Uso de variable local no asignada 'b'

¿Qué causa este problema? ¿Es posible solucionarlo a través de una configuración de compilador?

¿Qué causa este problema?

Me parece un error del compilador. Al menos, lo hizo. Aunque las expresiones decimal.TryParse(v, out a)y decimal.TryParse(v, out b)se evalúan dinámicamente, esperaba que el compilador aún entendiera que para cuando llegue a <= b, ambos ay bdefinitivamente están asignados. Incluso con las rarezas que se pueden encontrar en la escritura dinámica, esperaría evaluar solo a <= bdespués de evaluar ambas TryParsellamadas.

Sin embargo, resulta que a través del operador y la conversión engañosa, es completamente factible tener una expresión A && B && Cque evalúe Ay Cpero no B, si es lo suficientemente astuto. Consulte el informe de errores de Roslyn para ver el ingenioso ejemplo de Neal Gafter.

Hacer que funcione dynamices aún más difícil: la semántica involucrada cuando los operandos son dinámicos es más difícil de describir, porque para realizar una resolución de sobrecarga, es necesario evaluar los operandos para averiguar qué tipos están involucrados, lo que puede ser contrario a la intuición. Sin embargo, de nuevo Neal ha llegado con un ejemplo que demuestra que se requiere que el error del compilador ... esto no es un error, es un error del arreglo . Enormes felicitaciones a Neal por demostrarlo.

¿Es posible solucionarlo a través de la configuración del compilador?

No, pero existen alternativas que evitan el error.

En primer lugar, puede evitar que sea dinámico: si sabe que solo usará cadenas, entonces podría usar IEnumerable<string> o darle a la variable de rango vun tipo de string(es decir from string v in array). Esa sería mi opción preferida.

Si realmente necesita mantenerlo dinámico, simplemente dé bun valor para comenzar con:

decimal a, b = 0m;

Esto no hará ningún daño: sabemos que en realidad su evaluación dinámica no hará nada loco, por lo que aún terminará asignando un valor a bantes de usarlo, haciendo que el valor inicial sea irrelevante.

Además, parece que agregar paréntesis también funciona:

where decimal.TryParse(v, out a) && (decimal.TryParse("15", out b) && a <= b)

Eso cambia el punto en el que se activan varias piezas de resolución de sobrecarga, y hace feliz al compilador.

Hay una cuestión que aún permanecen - reglas de la especificación de la asignación definitiva a la &&necesidad del operador a aclararse a estado que sólo se aplican cuando el &&operador se está utilizando en su aplicación "regular" con dos booloperandos. Intentaré asegurarme de que esto se solucione para el próximo estándar ECMA.

Esto parece ser un error, o al menos una regresión, en el compilador de Roslyn. Se ha presentado el siguiente error para rastrearlo:

https://github.com/dotnet/roslyn/issues/4509

Mientras tanto, la excelente respuesta de Jon tiene un par de soluciones.

Como me educaron tan duro en el informe de errores, intentaré explicarlo yo mismo.

Imagine Tes un tipo definido por el usuario con una conversión implícita boolque alterna entre falsey true, comenzando con false. Por lo que el compilador sabe, el dynamicprimer argumento del primero &&podría evaluar ese tipo, por lo que tiene que ser pesimista.

Si, entonces, deja que el código se compile, esto podría suceder:

• Cuando el enlazador dinámico evalúa el primero &&, hace lo siguiente:
  • Evaluar el primer argumento
  • Es un T - implícitamente lo envía a bool.
  • Oh, lo es false, así que no necesitamos evaluar el segundo argumento.
  • Haga que el resultado de la &&evaluación sea el primer argumento. (No, no false, por alguna razón).
• Cuando el enlazador dinámico evalúa el segundo && , hace lo siguiente:
  • Evalúe el primer argumento.
  • Es un T- implícitamente lanzarlo abool.
  • Oh, es true , así que evalúe el segundo argumento.
  • ... Oh mierda, bno está asignado.

En términos de especificaciones, en resumen, existen reglas especiales de "asignación definida" que nos permiten decir no solo si una variable está "definitivamente asignada" o "no definitivamente asignada", sino también si está "definitivamente asignada después de la falseinstrucción" o "definitivamente asignado despuéstrue declaración ".

Estos existen para que al tratar con &&y ||(y !y ??y ?:) el compilador pueda examinar si se pueden asignar variables en ramas particulares de una expresión booleana compleja.

Sin embargo, estos solo funcionan mientras los tipos de expresiones permanecen booleanos . Cuando parte de la expresión es dynamic(o un tipo estático no booleano) ya no podemos decir de manera confiable que la expresión es trueo false; la próxima vez que la usemos boolpara decidir qué rama tomar, es posible que haya cambiado de opinión.

Actualización: esto ahora se ha resuelto y documentado :

Las reglas de asignación definidas implementadas por compiladores anteriores para expresiones dinámicas permitieron algunos casos de código que podrían resultar en la lectura de variables que no están asignadas definitivamente. Consulte https://github.com/dotnet/roslyn/issues/4509 para ver un informe al respecto.

...

Debido a esta posibilidad, el compilador no debe permitir que se compile este programa si val no tiene un valor inicial. Las versiones anteriores del compilador (anteriores a VS2015) permitieron que este programa se compilara incluso si val no tiene un valor inicial. Roslyn ahora diagnostica este intento de leer una variable posiblemente no inicializada.

Esto no es un error. Consulte https://github.com/dotnet/roslyn/issues/4509#issuecomment-130872713 para ver un ejemplo de cómo una expresión dinámica de este formulario puede dejar una variable sin asignar.