`switch boolValue` insists you do something with the false part, `if boolValue` does not. This is just looking at it from the most atomic level possible. If you have a group of booleans you get pretty complex lines of code. Switching on a tuple of three boolean where you can have cases like "if the first two are true ignore the third one" is super powerful. It becomes even better if you return an enum that indicates what it really means. Like CONNECTED, CONNECTING, DISCONNECTING, DISCONNECTED. Now every possible meaningful value of those three booleans has a word attached to it.

A Swift-enum allows you to have methods inside enums:

    enum ConnectionStatus {
        case connected
        case connecting
        case disconnecting
        case disconnected

        func `for`(isConnected: Bool, isConnecting: Bool, isDisconnecting: Bool) -> ConnectionStatus {
             switch (isConnected, isConnecting, isDisconnecting) {
             case (true, _, false): return .connected
             case (false, true, _): return .connecting
             case (true, _, false): return .disconnecting
             case (false, false, _): return .disconnected
        }
    }

Then somewhere inside your code:

    public func connect() {
        switch ConnectionStatus.for(isConnected: self.isConnected, isConnecting: self.isConnecting, isDisconnecting: self.isDisconnecting {
        case .connected, .connecting: return // We're already good
        case .disconnecting: reconnectWhenDisconnected()
        case .disconnected: startConnection()
    }

The amount of if's that have to be juggled to do the same and the resulting code that is hard to parse when you're maintaining it definitely is more problematic.

Whose comment are you responding to? It seems you agree with my comment about pattern matching and switch cases.

I must've misunderstood your comment. I thought you were saying these pattern matching rules were basically souped up if's. Elixir has pattern matching on function level but it's also heavily ingrained in the whole philosophy. It's quite the antithesis to Java.

The don't care _ is doing a lot of work keeping that code less verbose.