A case study for `reasync`

Evolution Discussion
41

Is it not the same with rethrows? (disregarding for a second that we have them already).

1 Like
42

no, in fact rethrows works in the complete opposite manner in that you can never generate a non-throwing overload, because we are not allowed to overload on throws.

that of course means that throws is immune to the DocC troubles that async has, but we also didn’t have the analogous “need to migrate Result<T, U>-returning APIs to the new colorful APIs” problem that we had with async, simply due to the order in which these features landed during Swift’s history.

if i remember correctly, allowing overloading on async was an explicit design choice made to accommodate migrating uncolored APIs to colored APIs. i’m not sure if anyone was thinking about how that would impact DocC at the time, as async probably predates DocC by several months.

2 Likes
43

You mean this won't work?

func throwingFunc() throws {
    print("throwingFunc")
    throw NSError(domain: "", code: 0)
}
func nonthrowingFunc() {
    print("nonThrowingFunc")
}
func proc(closure: () throws -> Void) throws {
    print("throwing version")
    try closure()
}
func proc(closure: () -> Void) {
    print("non throwing version")
    closure()
}
func test() {
    proc { nonthrowingFunc() }
    try! proc { try throwingFunc() }
}
test()
44

for some reason i always assumed the uniqueness checker (for lack of knowing the right term) was blind to all throws but it seems like it only ignores throws on the function signature itself and not throws in closure arguments.

1 Like