`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

`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.