switch con var / null comportamento strano

Dato il seguente codice:

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;
}

Perché la corrispondenza dell'istruzione switch è attiva case var o?

È mia comprensione che case string snon corrisponde quando s == nullperché (effettivamente) (null as string) != nullrestituisce falso. IntelliSense su VS Code mi dice che oè anche un file string. qualche idea?

Simile a: C # 7 switch case con controlli null

All'interno di switchun'istruzione di corrispondenza del modello che utilizza a caseper un tipo esplicito si chiede se il valore in questione è di quel tipo specifico o di un tipo derivato. È l'esatto equivalente diis

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

Il valore nullnon ha un tipo e quindi non soddisfa nessuna delle condizioni precedenti. Il tipo statico di someStringnon entra in gioco in nessuno dei due esempi.

Il vartipo anche se nella corrispondenza del modello agisce come un carattere jolly e corrisponderà a qualsiasi valore incluso null.

Il defaultcaso qui è codice morto. Il case var ocorrisponderà qualsiasi valore, null o non null. Un caso non predefinito vince sempre su uno predefinito, quindi defaultnon verrà mai colpito. Se guardi l'IL vedrai che non viene nemmeno emesso.

A prima vista può sembrare strano che questo si compili senza alcun preavviso (decisamente mi ha sbalordito). Ma questo corrisponde al comportamento di C # che risale a 1.0. Il compilatore consente defaultcasi anche quando può provare banalmente che non verrà mai colpito. Considera come esempio quanto segue:

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

Qui defaultnon verrà mai colpito (nemmeno perbool se ha un valore diverso da 1 o 0). Tuttavia C # lo ha consentito dalla 1.0 senza preavviso. Il pattern matching è in linea con questo comportamento qui.

Sto mettendo insieme più commenti su Twitter qui - questo in realtà è nuovo per me, e spero che jaredpar salti dentro con una risposta più completa, ma; versione breve a quanto ho capito:

case string s:

è interpretato come if(someString is string) { s = (string)someString; ...o if((s = (someString as string)) != null) { ... }- uno dei quali implica un nulltest - che è fallito nel tuo caso; al contrario:

case var o:

dove il compilatore si risolve ocome stringè semplicemente o = (string)someString; ...- nessun nulltest, nonostante il fatto che sia simile in superficie, solo con il compilatore che fornisce il tipo.

finalmente:

default:

qui non può essere raggiunto , perché il caso sopra cattura tutto. Potrebbe trattarsi di un bug del compilatore in quanto non ha emesso un avviso di codice non raggiungibile.

Sono d'accordo che questo è molto sottile e sfumato e confuso. Ma a quanto pare lo case var oscenario ha usi con propagazione nulla ( o?.Length ?? 0ecc.). Sono d'accordo sul fatto che sia strano che funzioni in modo molto diverso tra var oe string s, ma è ciò che fa attualmente il compilatore.

È perché case <Type>corrisponde al tipo dinamico (in fase di esecuzione), non al tipo statico (in fase di compilazione). nullnon ha un tipo dinamico, quindi non può corrispondere a string. varè solo il fallback.

(Pubblicare perché mi piacciono le risposte brevi.)