<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="">Moving “throws” or changing it to a prefix “throwing” as was originally suggested are relatively minor, reasonable improvements.<br class=""><div class=""><br class=""></div><div class="">We do need to consider if it restricts future language evolution (such as potentially listing all of the thrown errors), so that’s why it’s relevant to talk a little bit about that and what are options would be; but I think fundamental, non-backwards compatible changes to how you invoke throwing functions are probably too big to be reasonable.</div><div class=""><br class=""></div><div class="">- Karl</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 27 Dec 2016, at 22:31, Derrick Ho <<a href="mailto:wh1pch81n@gmail.com" class="">wh1pch81n@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Right. it should support the normal return type as well as the errors. Here is my revised suggestion.<br class=""><br class="">func foo() throws -> String {}<br class=""><br class="">switch try foo() {<br class="">case .returnValue(let value):<br class="">// do something with value<br class=""><br class="">case .MyEnumErrorFirstError:<br class="">// handle error<br class=""><br class="">default: <br class="">// handle NSError<br class="">}<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Dec 27, 2016 at 1:17 PM Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution <span dir="ltr" class="gmail_msg"><<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br class="gmail_msg"></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I suppose "throws" could be enhanced to produce a compiletime enum <br class="gmail_msg"><br class="gmail_msg">func bar() throws {<br class="gmail_msg">throw NSError()<br class="gmail_msg">throw MyEnumError.firstError<br class="gmail_msg">}<br class="gmail_msg"><br class="gmail_msg">Under the hood each expression passed to "throw" could make something like<br class="gmail_msg"><br class="gmail_msg">enum bar_abcdefj_throw {<br class="gmail_msg">case genericError // all NSError go here<br class="gmail_msg">case MyEnumErrorFirstError<br class="gmail_msg">}<br class="gmail_msg"><br class="gmail_msg">Where abcdefj is unique characters.<br class="gmail_msg"> <br class="gmail_msg"><br class="gmail_msg">This enum would only be visible through the catch blocks which would act like a switch statement.<br class="gmail_msg"><br class="gmail_msg">Speaking of switch statements do they currently support "try" expressions?<br class="gmail_msg"><br class="gmail_msg">switch try foo() {<br class="gmail_msg">case .MyEnumErrorFirstError:<br class="gmail_msg">// handle error<br class="gmail_msg">default: <br class="gmail_msg">// handle NSError and everything else<br class="gmail_msg">}<br class="gmail_msg"></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">If I'm not mistaken, `switch try foo()` switches over the return value of foo(); you'd switch over the error in a catch block.</div><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The benefit of this approach is that it would be additive. And no source breakage.<br class="gmail_msg"><br class="gmail_msg">At the risk of being off topic if there is interest in this I can start a new thread for this.<div class="m_6634727487067944581HOEnZb gmail_msg"><div class="m_6634727487067944581h5 gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Dec 27, 2016 at 9:54 AM Haravikk <<a href="mailto:swift-evolution@haravikk.me" class="gmail_msg" target="_blank">swift-evolution@haravikk.me</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><blockquote type="cite" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg">On 27 Dec 2016, at 13:43, Tino Heth <<a href="mailto:2th@gmx.de" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg" target="_blank">2th@gmx.de</a>> wrote:</div><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div style="word-wrap:break-word" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg">Imho this is no problem:</div><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg">Right now, we basically have "throws Error", and no matter what is actually thrown, we can always catch exhaustive by keeping the statement unspecific.</div></div></div></div></blockquote><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><br class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"></div></div></div><div style="word-wrap:break-word" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg">True, but for me it's more about knowing what a method can throw; currently to know that you need to consult documentation which, while fine, isn't the best way to do that when the compiler could know and it's then up to you whether to let it auto-complete for all throwable types, or just be generic for some or all of them (or pass the buck).</div></div></div><div style="word-wrap:break-word" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><br class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><blockquote type="cite" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div style="word-wrap:break-word" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><blockquote type="cite" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><span style="font-family:Monaco" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg">myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }</span></blockquote></div>Imho to much confusion with no real benefit:<div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg">Shouldn't it be up to the caller to decide which errors need special treatment? The library can't enforce proper handling at all.</div></div></blockquote><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><br class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"></div></div></div><div style="word-wrap:break-word" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg">Partly, but it's really just intended to distinguish things that are genuine runtime errors, versus things that shouldn't have happened, i.e- an illegal argument type error shouldn't occur if you're using a method correctly, so it's more like something you might check as an assertion. I should have been more clear that the main difference is in how fix-its might recommend the errors are handled; specific types would produce catch blocks, but optionals might be grouped into a catch-all at the end (e.g- they're special interest that you might not be bothered about), but the compiler would still be aware of them should you decide to add them.</div><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><br class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"></div><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg">If the distinctions not significant enough though then the "optional" error types could just be ignored for now, I think the more important ability is the ellipsis indicating "plus other errors" so we can specify either exhaustive lists of error types, or keep them open-ended, in which case the types listed are those that would be placed as catch blocks, with the ellipsis indicating that a catch-all is still required (or throw on the current method).</div></div></div><div style="word-wrap:break-word" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><br class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><blockquote type="cite" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div style="word-wrap:break-word" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg">One thing to note with explicit errors is that we'd basically introduce sum types…</div></div></blockquote></div></div><div style="word-wrap:break-word" class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"></div><br class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg">Not necessarily; you could think of explicit errors as being doing something like:</div><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><br class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"></div><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><span class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span" style="white-space:pre-wrap"> </span>enum MyErrorType {</div><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><span class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span" style="white-space:pre-wrap"> </span>case io_error(IOError)</div><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><span class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span" style="white-space:pre-wrap"> </span>case illegal_argument(IllegalArgumentError)</div><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><span class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span" style="white-space:pre-wrap"> </span>case unknown(Error)</div><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><span class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span" style="white-space:pre-wrap"> </span>}</div><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"><br class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg"></div><div class="m_6634727487067944581m_2322409923842249406gmail_msg gmail_msg">i.e- boilerplate we could do right now, but would prefer not to, but still allowing it to be handled as an enum.</div></div></blockquote></div>
</div></div><br class="gmail_msg"></blockquote></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
<br class="gmail_msg"></blockquote></div></div></div></blockquote></div>
</div></blockquote></div><br class=""></div></body></html>