Answer.

Pattern matching is a fundamental part of the Swift language, allowing for safe and elegant handling of different enum cases. This approach comes from functional languages where pattern matching allows for compact handling of various cases, avoiding long if-else chains. In Swift, pattern matching for enums is mainly implemented using switch, where each case is handled individually.

Problems arise when not all cases are implemented, or a default is chosen that potentially "hides" unaccounted cases. This can lead to runtime errors when new cases are added to the enum.

The solution is to explicitly enumerate all enum cases in switch, avoiding default (if possible). This approach ensures that when the enum is changed, the compiler will not miss unhandled cases.

Example code:

enum NetworkStatus {
    case connected
    case disconnected
    case connecting
}

func handle(status: NetworkStatus) {
    switch status {
    case .connected:
        print("Network is connected")
    case .disconnected:
        print("Network is disconnected")
    case .connecting:
        print("Connecting...")
    }
}

Key features:

Not using default makes pattern matching "exhaustive" and safe.
When new cases are added, the compiler requires a description of the new variant.
Switch for enums without associated values is maximally efficient and clean.

Trick questions.

1. Can if case expressions be used for enums without associated values?

Yes, they can. This allows for succinctly checking a specific case.

if case .connected = status {
    print("Network is connected")
}

2. Is it mandatory to implement default if all cases are used in switch?

No, if all variants are implemented, default is not required. It is better to avoid default — this way the compiler will signal when new cases are added.

3. Can fallthrough be used inside switch with enums?

Yes, it is possible, but highly discouraged as fallthrough does not consider the semantics of the case and can lead to logical errors.

Typical mistakes and anti-patterns

Adding default instead of explicit cases leads to silent errors when expanding enums.
Not handling new enum variants causes unexpected bugs.
Using fallthrough compromises code readability and reliability.

Real-life example

Negative case

A new case .noSignal is added to the enum NetworkStatus, but there is a default in the existing switch, so the error is only discovered at runtime when the status is not handled correctly.

Pros:

Less code, quicker to write.

Cons:

The error is not noticeable, leading to bugs in the future.

Positive case

All cases are explicitly handled. The compiler reports the need to update the switch immediately when a new case is added.