Swift 6 typed-throws unable to detect exhaustive catch statements

[NachoSoto]

Description

Consider the example below. Both Error.a and Error.b are caught, but the compiler is unable to infer that.

Reproduction

enum Error: Swift.Error {
  case a
  case b
}

func f() throws(Error) {
  throw .a
}

func g() {
  do {
    // Errors thrown from here are not handled because the enclosing catch is not exhaustive
    try f()
  } catch .a {
  } catch .b {
  }
}

Expected behavior

Code compiles

Environment

swift-driver version: 1.109.2 Apple Swift version 6.0 (swiftlang-6.0.0.3.300 clang-1600.0.20.10)
Target: arm64-apple-macosx14.0

Additional information

No response

[robertmryan]

Just an additional data point. Consider:

enum MyError: Error {
    case one
    case two
}

func funcWithTypedThrow() async throws(MyError) {…}

As NachoSoto pointed out, if you use separate catch statements for those individual MyError cases, the compiler will incorrectly conclude that the catches are not exhaustive:

// An example where typed-throw correctly infers the type of the thrown error, but
// incorrectly concludes catch is not exhaustive.

func foo() async {
    do {
        try await funcWithTypedThrow() // Swift 6.0 compiler incorrectly produces error: “Errors thrown from here are not handled because the enclosing catch is not exhaustive”
    } catch .one {
        print("one")
    } catch .two {
        print("two")
    }
}

Interestingly, if we add an extra catch to silence that error, the compiler now realizes that this is unnecessary and will warn that it “will never be executed”:

// In this example, I added extra `catch` to silence the above error, but now 
// the compiler now warns us that that this extra `catch` is unnecessary.

func bar() async {
    do {
        try await funcWithTypedThrow()
    } catch .one {
        print("one")
    } catch .two {
        print("two")
    } catch {  // Swift 6.0 compiler correctly produces warning: “Case will never be executed”
        print("this is required to silence 'non-exhaustive' error, but generates a 'will never be executed' warning")
    }
}

So, it is not the case that it is entirely unaware of the exhaustive catch statements (because it notices if you add the redundant catch), but it just has a false positive error in the absence of the redundant catch.

[NachoSoto]

Another example (repro-ing on 6.0.3):

enum E: Error {
  case e1
}

func f() throws(E) {
  throw .e1
}

func g() {
  do {
    // Errors thrown from here are not handled because the enclosing catch is not exhaustive
    try f()
  } catch E.e1 {}
}

[robertmryan]

FWIW, the issue persists in Swift version 6.1 (swiftlang-6.1.0.109.103 clang-1700.0.13.2), from Xcode 16.3 beta 2, too.

---

For what it is worth, in the interim, one can use a switch statement, instead:

enum MyError: Error {
    case one
    case two
}

func funcWithTypedThrow() async throws(MyError) {…}

func baz() async {
    do {
        try await funcWithTypedThrow()
    } catch {
        switch error {
        case .one: print("one")
        case .two: print("two")
        }
    }
}

Again, it illustrates that it clearly understands that error is a MyError. And this gets around the false positive error message of the simple catch .one/catch .two pattern. This switch is ugly, but it works.

[xwu]

As @Jumhyn mentioned over in #74554, this behavior is by design, as spelled out in SE-0413 (emphasis added):

Note that the only way to write an exhaustive do...catch statement is to have an unconditional catch block.