On Thu, Aug 17, 2017, at 10:04 PM, Chris Lattner via swift-evolution wrote:> That said, I don’t feel like I have enough data to have a strong > opinion on it. The missing link for me is exactly how pervasive the > non-throwing cocoa completion handlers are. If it turns out that > people would have to confront "async(nonthrowing)” in practice (as > opposed to being an obscure corner that the compiler implementers have > to care about) then it is probably the wrong design. It may be helpful to look at data points outside of Cocoa. We use a Future framework that distinguishes between plain old `Future<T>` and `Future<Result<T>>`. In a back-of-the-hand calculation, about 10% of our futures don’t use Result. It’s rarer, but it is useful; it aligns well with the Error manifesto’s notion of a domain failures. I think I’m overall in favor of an implicitly throwing model, though. Not only is it cleaner, but it’ll simplify all sorts of abstractions. f.ex: In our use of this framework, collecting up errors or cancellations for an array of tasks is a perennial problem. `Future<T?>` (and similarly `async -> T?`) can be plenty useful, but I’m not sure they pull their weight enough to deserve occupying the best syntax. (Huge, huge +1 to the whole shebang, though. Let’s just do this!!!)
Sincerely, Zachary Waldowski z...@waldowski.me
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
