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.

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 {}
}

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.

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.

This just caught me by surprise. Especially as the compiler gives you an error to say you need an unconditional catch block, which if you add it then produces a warning that it's unexecutable. No sane language should tell you do something and then immediately tell you, you don't need it.

This should be basically syntax sugar

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

For this:

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

@xwu said:

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

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

I would not say it is “by design”, but rather more of an acknowledged limitation. As they say a few lines later:

Note: Exhaustiveness checking in the general is expensive at compile time, and the existing language uses the presence of an unconditional catch block as the indicator for an exhaustive do...catch.

So, its not that it was designed with the intent of adding the unnecessary unconditional catch, but rather that it was a compromise introduced to reduce the burden at compile time. But, yes, they know about the problem.

My point is that it’s not reasonable for the compiler to complain that the “Case will never be executed” when it was the compiler that insisted in the unnecessary unconditional catch in the first place. Ideally, the compiler needs to eliminate this unconditional catch requirement, or, worst case scenario, remove the warning about the unconditional catch that it forced us to introduce.