<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=""><div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 20, 2017, at 9:57 AM, John McCall via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class="">On Feb 19, 2017, at 3:04 PM, Anton Zhilin via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><div class=""><div dir="ltr" class=""><div class="markdown-here-wrapper"><p class="" style="margin: 0px 0px 1.2em !important;">It’s expected that if you need resilience, then you will throw an “open” enum. Essentially, we pass resilience of typed<span class="Apple-converted-space">&nbsp;</span><code class="" style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace; margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; display: inline;">throws</code><span class="Apple-converted-space">&nbsp;</span>on to those who will hopefully establish resilience of enums.</p><p class="" style="margin: 0px 0px 1.2em !important;">If you prefer separate error types, then declare a base protocol for all your error types and throw a protocol existential. You won’t even need default case in switches, if closed protocols make it into the language.</p><p class="" style="margin: 0px 0px 1.2em !important;">I don’t like any solution that is based on comments. I think that compiler should always ignore comments.</p></div></div></div></blockquote><div class="">I agree. &nbsp;And in general, this sort of thing is exactly my core concern about adding typed throws to the language: I am completely certain that many programmers will add typed throws annotations because they're programmers and thus, well, probably a little obsessive/compulsive, and they're trying to precisely document the behavior of their function without necessarily thinking about the usefulness of that information for their clients and (if they're writing a library; and really you should almost always be writing code as if you're writing a library) whether they're actually willing to commit to that behavior in their interface. &nbsp;For those programmers, typed throws is just going to box them in and force them into anti-patterns in the long run.</div></div></div></blockquote></div></div></div></div><br class=""><div class="">As you know, I still think that adding typed throws is the right thing to do. &nbsp;I understand your concern about “the feature could be misused” but the same thing is true about many other language features.</div><div class=""><br class=""></div><div class="">One thing you didn’t mention is that boxing thrown values in an existential requires allocation in the general case. &nbsp;This may be unacceptable for some classes of Swift application (in the embedded / deep systems space) or simply undesirable because of the performance implication.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></body></html>