<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 10, 2017, at 10:35 PM, Russ Bishop via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 28, 2016, at 8:11 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On Dec 28, 2016, at 7:47 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">I thought there is already a pending proposal on typed throws?<br class=""></blockquote><br class="">There was, I vaguely recall that it was by Russ? I don’t see any open PRs for it.</div></div></blockquote><div class=""><br class=""></div><div class="">Hey now, there is no need for name calling ;)</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><br class="">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).</div></div></blockquote><div class=""><br class=""></div><div class="">I fall firmly in John McCall’s camp on this one. If someone wants to read that part of the thread: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000958.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000958.html</a></div><div class=""><br class=""></div></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><br class=""></div><div>If Swift has a canonical built-in system for reporting an Error, why wouldn't it be used here? Why use casting?</div><div><br class=""></div><div>-- E</div><div><br class=""></div><br class=""></body></html>