> On Jan 10, 2017, at 10:35 PM, Russ Bishop via swift-evolution > <[email protected]> wrote: > > >> On Dec 28, 2016, at 8:11 PM, Chris Lattner via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> On Dec 28, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
