cambiar con var / null comportamiento extraño

Dado el siguiente código:

string someString = null;
switch (someString)
{
    case string s:
        Console.WriteLine("string s");
        break;
    case var o:
        Console.WriteLine("var o");
        break;
    default:
        Console.WriteLine("default");
        break;
}

¿Por qué la declaración del interruptor coincide case var o?

Tengo entendido que case string sno coincide cuando s == nullporque (efectivamente) se (null as string) != nullevalúa como falso. IntelliSense en VS Code me dice que oes unstring . ¿Alguna idea?

Similar a: caso de conmutador C # 7 con comprobaciones nulas

Dentro de una switchdeclaración de coincidencia de patrones que usa casepara un tipo explícito, se pregunta si el valor en cuestión es de ese tipo específico o de un tipo derivado. Es el equivalente exacto deis

switch (someString) {
  case string s:
}
if (someString is string) 

El valor nullno tiene un tipo y, por lo tanto, no cumple ninguna de las condiciones anteriores. El tipo estático de someStringno entra en juego en ningún ejemplo.

El vartipo aunque en la coincidencia de patrones actúa como un comodín y coincidirá con cualquier valor incluyendo null.

El defaultcaso aquí es un código muerto. El case var ocoincidirá con cualquier valor, nulo o no nulo. Un caso no predeterminado siempre gana sobre uno predeterminado, por defaultlo que nunca se alcanzará. Si miras el IL, verás que ni siquiera se emite.

De un vistazo, puede parecer extraño que esto se compile sin ninguna advertencia (definitivamente me desconcertó). Pero esto coincide con el comportamiento de C # que se remonta a 1.0. El compilador admite defaultcasos incluso cuando puede demostrar trivialmente que nunca se alcanzará. Considere como ejemplo lo siguiente:

bool b = ...;
switch (b) {
  case true: ...
  case false: ...
  default: ...
}

Aquí defaultnunca se activará (incluso si booltiene un valor que no sea 1 o 0). Sin embargo, C # ha permitido esto desde la versión 1.0 sin previo aviso. La coincidencia de patrones simplemente se ajusta a este comportamiento aquí.

Estoy reuniendo varios comentarios de Twitter aquí; esto es realmente nuevo para mí, y espero que Jaredpar intervenga con una respuesta más completa, pero; versión corta como yo lo entiendo:

case string s:

se interpreta como if(someString is string) { s = (string)someString; ...o if((s = (someString as string)) != null) { ... }(cualquiera de los cuales implica una nullprueba) que ha fallado en su caso; Por el contrario:

case var o:

donde se resuelve el compilador oque stringes simplemente o = (string)someString; ...- no hay nullprueba, a pesar del hecho de que sea similar en la superficie, sólo con el compilador proporcionar el tipo.

finalmente:

default:

aquí no se puede llegar , porque el caso anterior lo atrapa todo. Esto puede ser un error del compilador porque no emitió una advertencia de código inalcanzable.

Estoy de acuerdo en que esto es muy sutil, matizado y confuso. Pero aparentemente el case var oescenario tiene usos con propagación nula ( o?.Length ?? 0etc.). Estoy de acuerdo en que es extraño que esto funcione de manera tan diferente entre var oy string s, pero es lo que hace actualmente el compilador.

Es porque case <Type>coincide con el tipo dinámico (tiempo de ejecución), no el tipo estático (tiempo de compilación). nullno tiene un tipo dinámico, por lo que no puede coincidir con string. vares solo la alternativa.

(Publicando porque me gustan las respuestas cortas).