Risposta

Il pattern matching per le tuple in Swift consente di confrontare e decomprimere comodamente i valori. Nel switch è possibile analizzare le tuple direttamente nel pattern:

let point = (x: 0, y: 2)
switch point {
  case (0, 0):
    print("All'origine delle coordinate")
  case (0, let y):
    print("x = 0, y = \(y)")
  case let (x, y) where x == y:
    print("x è uguale a y")
  default:
    print("Un altro punto")
}

Sottigliezze:

• Il numero e l'ordine degli elementi devono corrispondere alla tupla.
• Il possible binding e le espressioni guard funzionano come per le normali variabili.
• È possibile un exhaustiveness check solo per tuple di valori per cui è definito un intervallo completo.

Domanda trabocchetto

È possibile utilizzare il confronto di una tupla di tipo (String, Int) con un case-pattern di tipi diversi, ad esempio case (let a, let b):?

Spesso si risponde di sì, ma è importante che i tipi delle variabili nel pattern corrispondano rigorosamente al tipo della tupla.

let pair = ("abc", 5)
switch pair {
case (let text, let number):
   print("Stringa: \(text), numero: \(number)") // Ok
case (let x, let y) where x == y:
   print("Errore")  // Errore: L'operatore binario '==' non può essere applicato agli operandi di tipo 'String' e 'Int'
default: break
}

Se i tipi non coincidono, il compilatore genererà un errore durante la compilazione.

Esempi di errori reali causati dall'ignoranza delle sottigliezze del tema

---

Storia

In un progetto si cercava di utilizzare switch-case per analizzare la risposta del server come tupla, senza considerare i possibili valori nil. Questo portava al fatto che nessun case corrispondeva e si attivava il default, anche se era prevista un'altra logica.

---

Storia

Incompatibilità dei tipi: nella funzione, il gestore della tupla riceveva (Int, String), ma si cercava di decomprimere come (String, Int). Risultato — crash durante la compilazione e tempo perso nella ricerca della causa.

---

Storia

Si utilizzava guard per decomprimere la tupla del risultato senza considerare il caso di valori negativi, sebbene la logica di gestione fosse prevista solo per numeri positivi. Di conseguenza, parte dei casi validi veniva ignorata, il che si rivelava un problema nella logica di business.