<div dir="ltr"><div>Agree, it doesn&#39;t seem to read naturally at first glance.</div><div><br></div><div>However, one way perhaps to think about the rationale for this is that `throws` does &quot;fit&quot; logically between the parameters and the return type: a function that throws might take certain arguments and, by throwing, never return a value of the stated return type. In that perspective, `throws` could be justified in its current position interposed between the input and the desired output.</div><div><br></div><div><br></div>On Tue, Dec 27, 2016 at 4:51 PM, thislooksfun via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">If some form of explicitly typed errors is added, my initial problem goes away. The only reason I suggested the move in the first place, is that a combination of `throws` and return (-&gt; T) statements makes it <i>look</i> like there is already explicitly typed errors, especially to those of us coming from Java.<br><div>
<div style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word"><br>-thislooksfun (tlf)</div>

</div><div><div class="h5">

<br><div><blockquote type="cite"><div>On Dec 27, 2016, at 3:41 PM, Karl via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_8597572834478154638Apple-interchange-newline"><div><div style="word-wrap:break-word">Moving “throws” or changing it to a prefix “throwing” as was originally suggested are relatively minor, reasonable improvements.<br><div><br></div><div>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><br></div></div></div></blockquote></div></div></div></div></blockquote><div><br></div><div>I&#39;m -1 on big changes such as suggested as well. The deliberate choice to separate error handling from other code with `do { }` was a deliberate design choice and it&#39;d be very disruptive to break that now. And in terms of just gut feeling, switching over errors and return values at the same time seems like going in the wrong direction.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div></div><div>- Karl</div><div><br><div><blockquote type="cite"><div>On 27 Dec 2016, at 22:31, Derrick Ho &lt;<a href="mailto:wh1pch81n@gmail.com" target="_blank">wh1pch81n@gmail.com</a>&gt; wrote:</div><br class="m_8597572834478154638Apple-interchange-newline"><div>Right.  it should support the normal return type as well as the errors.  Here is my revised suggestion.<br><br>func foo() throws -&gt; String {}<br><br>switch try foo() {<br>case .returnValue(let value):<br>// do something with value<br><br>case .MyEnumErrorFirstError:<br>// handle error<br><br>default: <br>// handle NSError<br>}<br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 27, 2016 at 1:17 PM Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_8597572834478154638gmail_msg">On Tue, Dec 27, 2016 at 4:03 PM, Derrick Ho via swift-evolution <span dir="ltr" class="m_8597572834478154638gmail_msg">&lt;<a href="mailto:swift-evolution@swift.org" class="m_8597572834478154638gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br class="m_8597572834478154638gmail_msg"></div><div dir="ltr" class="m_8597572834478154638gmail_msg"><div class="gmail_extra m_8597572834478154638gmail_msg"><div class="gmail_quote m_8597572834478154638gmail_msg"><blockquote class="gmail_quote m_8597572834478154638gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I suppose &quot;throws&quot; could be enhanced to produce a compiletime enum <br class="m_8597572834478154638gmail_msg"><br class="m_8597572834478154638gmail_msg">func bar() throws {<br class="m_8597572834478154638gmail_msg">throw NSError()<br class="m_8597572834478154638gmail_msg">throw MyEnumError.firstError<br class="m_8597572834478154638gmail_msg">}<br class="m_8597572834478154638gmail_msg"><br class="m_8597572834478154638gmail_msg">Under the hood each expression passed to &quot;throw&quot; could make something like<br class="m_8597572834478154638gmail_msg"><br class="m_8597572834478154638gmail_msg">enum bar_abcdefj_throw {<br class="m_8597572834478154638gmail_msg">case genericError // all NSError go here<br class="m_8597572834478154638gmail_msg">case MyEnumErrorFirstError<br class="m_8597572834478154638gmail_msg">}<br class="m_8597572834478154638gmail_msg"><br class="m_8597572834478154638gmail_msg">Where abcdefj is unique characters.<br class="m_8597572834478154638gmail_msg"> <br class="m_8597572834478154638gmail_msg"><br class="m_8597572834478154638gmail_msg">This enum would only be visible through the catch blocks which would act like a switch statement.<br class="m_8597572834478154638gmail_msg"><br class="m_8597572834478154638gmail_msg">Speaking of switch statements do they currently support &quot;try&quot; expressions?<br class="m_8597572834478154638gmail_msg"><br class="m_8597572834478154638gmail_msg">switch try foo() {<br class="m_8597572834478154638gmail_msg">case .MyEnumErrorFirstError:<br class="m_8597572834478154638gmail_msg">// handle error<br class="m_8597572834478154638gmail_msg">default: <br class="m_8597572834478154638gmail_msg">// handle NSError and everything else<br class="m_8597572834478154638gmail_msg">}<br class="m_8597572834478154638gmail_msg"></blockquote><div class="m_8597572834478154638gmail_msg"><br class="m_8597572834478154638gmail_msg"></div></div></div></div><div dir="ltr" class="m_8597572834478154638gmail_msg"><div class="gmail_extra m_8597572834478154638gmail_msg"><div class="gmail_quote m_8597572834478154638gmail_msg"><div class="m_8597572834478154638gmail_msg">If I&#39;m not mistaken, `switch try foo()` switches over the return value of foo(); you&#39;d switch over the error in a catch block.</div><div class="m_8597572834478154638gmail_msg"> </div><blockquote class="gmail_quote m_8597572834478154638gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div><div dir="ltr" class="m_8597572834478154638gmail_msg"><div class="gmail_extra m_8597572834478154638gmail_msg"><div class="gmail_quote m_8597572834478154638gmail_msg"><blockquote class="gmail_quote m_8597572834478154638gmail_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="m_8597572834478154638gmail_msg"><br class="m_8597572834478154638gmail_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_8597572834478154638m_6634727487067944581HOEnZb m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581h5 m_8597572834478154638gmail_msg"><br class="m_8597572834478154638gmail_msg"><div class="gmail_quote m_8597572834478154638gmail_msg"><div dir="ltr" class="m_8597572834478154638gmail_msg">On Tue, Dec 27, 2016 at 9:54 AM Haravikk &lt;<a href="mailto:swift-evolution@haravikk.me" class="m_8597572834478154638gmail_msg" target="_blank">swift-evolution@haravikk.me</a>&gt; wrote:<br class="m_8597572834478154638gmail_msg"></div><blockquote class="gmail_quote m_8597572834478154638gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><blockquote type="cite" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg">On 27 Dec 2016, at 13:43, Tino Heth &lt;<a href="mailto:2th@gmx.de" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg" target="_blank">2th@gmx.de</a>&gt; wrote:</div><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div style="word-wrap:break-word" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg">Imho this is no problem:</div><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg">Right now, we basically have &quot;throws Error&quot;, 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_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><br class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"></div></div></div><div style="word-wrap:break-word" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg">True, but for me it&#39;s more about knowing what a method can throw; currently to know that you need to consult documentation which, while fine, isn&#39;t the best way to do that when the compiler could know and it&#39;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_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><br class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><blockquote type="cite" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div style="word-wrap:break-word" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><blockquote type="cite" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><span style="font-family:Monaco" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg">myMethod(args:[String:Any]) throws IOError, IllegalArgumentError? { … }</span></blockquote></div>Imho to much confusion with no real benefit:<div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg">Shouldn&#39;t it be up to the caller to decide which errors need special treatment? The library can&#39;t enforce proper handling at all.</div></div></blockquote><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><br class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"></div></div></div><div style="word-wrap:break-word" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg">Partly, but it&#39;s really just intended to distinguish things that are genuine runtime errors, versus things that shouldn&#39;t have happened, i.e- an illegal argument type error shouldn&#39;t occur if you&#39;re using a method correctly, so it&#39;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&#39;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_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><br class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"></div><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg">If the distinctions not significant enough though then the &quot;optional&quot; error types could just be ignored for now, I think the more important ability is the ellipsis indicating &quot;plus other errors&quot; 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_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><br class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><blockquote type="cite" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div style="word-wrap:break-word" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg">One thing to note with explicit errors is that we&#39;d basically introduce sum types…</div></div></blockquote></div></div><div style="word-wrap:break-word" class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"></div><br class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg">Not necessarily; you could think of explicit errors as being doing something like:</div><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><br class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"></div><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><span class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg m_8597572834478154638m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span" style="white-space:pre-wrap">        </span>enum MyErrorType {</div><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><span class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg m_8597572834478154638m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span" style="white-space:pre-wrap">                </span>case io_error(IOError)</div><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><span class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg m_8597572834478154638m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span" style="white-space:pre-wrap">                </span>case illegal_argument(<wbr>IllegalArgumentError)</div><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><span class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg m_8597572834478154638m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span" style="white-space:pre-wrap">                </span>case unknown(Error)</div><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><span class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg m_8597572834478154638m_6634727487067944581m_2322409923842249406m_7179559898482663862Apple-tab-span" style="white-space:pre-wrap">        </span>}</div><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"><br class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_msg"></div><div class="m_8597572834478154638m_6634727487067944581m_2322409923842249406gmail_msg m_8597572834478154638gmail_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="m_8597572834478154638gmail_msg"></blockquote></div></div></div><div dir="ltr" class="m_8597572834478154638gmail_msg"><div class="gmail_extra m_8597572834478154638gmail_msg"><div class="gmail_quote m_8597572834478154638gmail_msg"><blockquote class="gmail_quote m_8597572834478154638gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">______________________________<wbr>_________________<br class="m_8597572834478154638gmail_msg">
swift-evolution mailing list<br class="m_8597572834478154638gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_8597572834478154638gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_8597572834478154638gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_8597572834478154638gmail_msg" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br class="m_8597572834478154638gmail_msg">
<br class="m_8597572834478154638gmail_msg"></blockquote></div></div></div></blockquote></div>
</div></blockquote></div><br></div></div>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>