Si tengo una declaración if como if (currentShape is ITable table || currentShape is AutoShape autoShape) no puedo usar table o autoShape en el cuerpo porque aparece un error de compilación CS0165 .
Lo mismo es cierto para una sentencia switch con fall-through:
void Foo(object o) { switch (o) { case int i: case string s: case Guid g: string bar = i?.ToString() ?? s?.ToString() ?? g.ToString(); // cannot use i, s, or g. break; } } Entiendo por qué, pero me pregunto, ¿es esto una limitación de la coincidencia de patrones, es decir, no puede usarlo en declaraciones compuestas if , o hay una forma correcta de construir la declaración para que pueda usar cualquiera de las variables (por ejemplo, inicializándolas a nulo para poder al menos hacer una verificación nula)?
Desde C# 9 puedes hacer lo siguiente
con declaración de cambio
switch (o) { case object probe when probe is int or string or Guid: string bar = probe.ToString(); break; }y con expresión de cambio
var bar = o switch { int or string or Guid => o.ToString() };Si realmente hay dos cosas separadas que lograr, no combine las expresiones de patrones. Dos sentencias if separadas funcionarán mejor.
if (currentShape is ITable table) { // do something with tables } if (currentShape is AutoShape autoShape) { // do something with autoshapes } Sin embargo, su otro ejemplo ilustra que quizás haya alguna funcionalidad común entre las condiciones. ToString() es probablemente un mal ejemplo, como podrías hacer:
string? bar = o.ToString(); // doesn't matter the type of objectPero digamos que tal vez desee que se aplique un formato diferente según el tipo. En ese caso, una expresión de cambio podría ser útil. Por ejemplo:
string? bar = o switch { int i => i.ToString("D3"), // three digits Guid g => g.ToString("N"), // no hyphens string s => s, // no need to call ToString on a string _ => o.ToString() // all other types }; También preguntó si las variables podrían inicializarse con valores nulos para poder realizar una verificación de valores nulos. Eso no funcionaría para tipos que no aceptan valores NULL como int . Para tipos anulables, causaría operaciones de comparación extrañas (primero para probar el tipo y asignar nulo, segundo para probar nulo). Mantener las expresiones separadas garantiza el mínimo número de operaciones.