[Pitch N+1] Typed Throws

[tcldr]

@Jumhyn

@xwu

In my view, at least, there's little utility in debating whether the scenarios in which these two are not equivalent constitute only "weird" cases[*],

To be clear, in my use of the word 'weird' I didn't mean to dismiss any motivation for the "throw the same type even when input function hasn't actually thrown" behavior (I agree with you that some sort of caching behavior like you mention seems pretty reasonable). A better word would likely be 'obscure' instead, construed as applying narrowly to the hoops implementors are required to jump through to achieve that behavior.

For me, the bigger issue is that we're not applying the same strict judgement to rethrows that we do to the typed throws equivalent. For example, it's fairly trivial to 'break-out' of the intended semantics of rethrows, too:

struct MyError: Error {}

func f(_ a: () throws -> Void) rethrows {
  func g(_ b: () throws -> Void) throws {
    throw MyError()
  }
  try g(a)
}

In this example, the supplied closure, a, is never called yet MyError is thrown. This clearly breaks the intended semantics of 'f should throw if and only if a throws'.

EDIT: To be fair, this method does trigger a runtime exception when called with a non-throwing function.