> On Jan 11, 2017, at 10:35 AM, Erica Sadun <er...@ericasadun.com> wrote: > >> >> On Jan 10, 2017, at 10:35 PM, Russ Bishop via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Dec 28, 2016, at 8:11 PM, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>>> On Dec 28, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> I thought there is already a pending proposal on typed throws? >>> >>> There was, I vaguely recall that it was by Russ? I don’t see any open PRs >>> for it. >> >> Hey now, there is no need for name calling ;) >> >> >>> >>> I’m personally a big fan of typed throws, but I know that John McCall has >>> strong concerns. I can’t argue that typed throws is a high priority at the >>> moment, but as soon as we start talking about concurrency the topic of a >>> Result type will come back up (for use with futures/async). >> >> I fall firmly in John McCall’s camp on this one. If someone wants to read >> that part of the thread: >> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000958.html >> >> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000958.html> >> >> Of course if we want to automatically convert a throws function into an >> awaitable Result then that naturally begs the question of either Result’s >> error is typed as Error or not. I think I fall into the “as Error” camp here >> too because Swift’s switch is powerful enough to pattern match on the type >> fairly nicely but I haven’t thought about it very much. >> >> >> All that said… if Swift got a macro system Rust’s error-chain seems to have >> some interesting ideas that avoid a lot of boilerplate. > > If Swift has a canonical built-in system for reporting an Error, why wouldn't > it be used here? Why use casting? > > — E
I was using shorthand for “struct Result<T> { let error: Error? }” vs “struct Result<T, E: Error> { let error: E? }”… as in I prefer not having a second generic type parameter to denote the error. Russ
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution