Odpowiedź

Dopasowanie wzorców dla krotek w Swift umożliwia wygodne porównywanie i rozpakowywanie wartości. W instrukcji switch można rozbierać krotki bezpośrednio w wzorze:

let point = (x: 0, y: 2)
switch point {
  case (0, 0):
    print("W punkcie zerowym")
  case (0, let y):
    print("x = 0, y = \(y)")
  case let (x, y) where x == y:
    print("x jest równe y")
  default:
    print("Inny punkt")
}

Niuanse:

• Liczba i kolejność elementów muszą odpowiadać krotce.
• Wyrażenia typu possible binding i guard działają tak samo jak w przypadku zwykłych zmiennych.
• Możliwa jest kontrola wyczerpania tylko dla krotek z wartościami, dla których zdefiniowany jest pełny zakres.

Pytanie z haczykiem

Czy można w instrukcji switch-case używać porównania krotki typu (String, Int) z wzorem case z różnych typów, np. case (let a, let b):?

Często odpowiada się, że to możliwe, ale ważne jest, aby typy zmiennych w wzorze ściśle odpowiadały typowi krotki.

let pair = ("abc", 5)
switch pair {
case (let text, let number):
   print("Tekst: \(text), liczba: \(number)") // Ok
case (let x, let y) where x == y:
   print("Błąd")  // Błąd: Operator binarny '==' nie może być zastosowany do operandów typu 'String' i 'Int'
default: break
}

Jeśli typy się nie zgadzają, kompilator zgłosi błąd w czasie kompilacji.

Przykłady rzeczywistych błędów z powodu braku znajomości niuansów tematu

---

Historia

W jednym z projektów próbowano użyć instrukcji switch-case do analizy odpowiedzi serwera jako krotki, nie biorąc pod uwagę możliwych wartości nil. Prowadziło to do sytuacji, w której żaden case nie pasował, a wykonywał się default, mimo że planowano inną logikę.

---

Historia

Niezgodność typów: w funkcji obsługującej krotkę otrzymano (Int, String), a próbowano rozpakować jako (String, Int). Rezultat — awaria na etapie kompilacji i stracony czas na poszukiwanie przyczyny.

---

Historia

Użyto guard do rozpakowania krotki wyniku bez uwzględnienia przypadku z wartościami ujemnymi, mimo że przetwarzanie przewidywano tylko dla liczb dodatnich. W rezultacie część prawidłowych przypadków została zignorowana, co okazało się problemem w logice biznesowej.