<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="">My intended framing of this does not seem to be coming across in my arguments. I am not thinking of this as a way to avoid typing ‘try!’ or ‘try?’. This is not intended to replace any of the current uses of ‘throws’. Rather, it is intended to replace trapping and nil-returning functions where converting it to throw would be burdensome in the most common use cases, but still desirable in less common use cases. In my mind, it is only enabling the author to provide extra information and flexibility, compared to the current behavior.<div class=""><br class=""></div><div class="">For example, let’s say I have a failable initializer, which could fail for 2 or 3 different reasons, and that the vast majority of use-cases I only care whether it succeeded or not (which is why nil-returning was chosen)… but there may be a rare case or two where I really would prefer to probe deeper (and changing it to a throwing initializer would inhibit the majority cases). Then using ’throws?’ allows the primary usage to remain unchanged, while allowing users to opt-in to throwing behavior when desired.</div><div class=""><br class=""></div><div class="">Right now I end up making multiple functions, which are identical except for throw vs nil-return, and must now be kept in sync. I’ll admit it isn’t terribly common, but it has come up enough that I think it would still be useful.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">The other argument I will make is one of symmetry. We have 3 different types of error handling in swift: throwing, optional-returns, and trapping. There is already some ability to convert between these:</div><div class=""><br class=""></div><div class="">If you have a throwing function:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>‘try?’ allows you to convert to optional-return</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>‘try!’ allows you to convert to trapping</div><div class=""><br class=""></div><div class="">If you have an optional-return:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>‘!’ allows you to convert to trapping</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>you are unable to convert to throwing (because it requires extra info which isn’t available)</div><div class=""><br class=""></div><div class="">If you have a trapping function, you are unable to convert to either.</div><div class=""><br class=""></div><div class="">With ‘throws?’ you have an optional return which you can convert to throwing with ‘try’</div><div class=""><br class=""></div><div class="">With ‘throws!’ you have a trapping function where:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>‘try?’ allows you to convert to optional-return</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>‘try’ allows you to convert to throwing</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thus, ‘throws?’ and ‘throws!’ allow you provide optional-return and trapping functions where extra information is provided so that it is possible to convert to throwing when desired. In cases where this conversion is not appropriate, the author would simply continue to use the current methods.</div><div class=""><br class=""></div><div class="">Basically it is useful in designs where optional-return or trapping were ultimately chosen, but there was also a strong case to be made for making it a throwing function. I think the fears of people using it instead of ‘throws’ are unfounded because they already have the ability to use optionals or trapping… this just mitigates some of the losses from those choices. </div><div class=""><br class=""></div><div class="">Does that make more sense? </div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jan 12, 2017, at 5:34 PM, Greg Parker <<a href="mailto:gparker@apple.com" class="">gparker@apple.com</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 Jan 12, 2017, at 4:46 PM, Xiaodi Wu 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 dir="ltr" class=""><blockquote type="cite" class="">On Thu, Jan 12, 2017 at 6:27 PM, Jonathan Hull <span dir="ltr" class=""><<a href="mailto:jhull@gbis.com" target="_blank" class="">jhull@gbis.com</a>></span> wrote:<br class=""></blockquote><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""></div></blockquote></div></div></div></div></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class="">Also, ‘try’ is still required to explicitly mark a potential error propagation point, which is what it was designed to do. You don’t have ‘try’ with the variants because it is by default no longer a propagation point (unless you make it one explicitly with ’try’).<br class=""></blockquote></blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">If this is quite safe and more convenient, why then shouldn't it be the behavior for `throws`? (That is, why not just allow people to call throwing functions without `try` and crash if the error isn't caught? It'd be a purely additive proposal that's backwards compatible for all currently compiling code.)</div></div></div></div></div></blockquote></div><br class=""><div class="">Swift prefers that potential runtime crash points be visible in the code. You can ignore a thrown error and crash instead, but the code will say `try!`. You can force-unwrap an Optional and crash if it is nil, but the code will say `!`. </div><div class=""><br class=""></div><div class="">Allowing `try` to be omitted would obscure those crash points from humans reading the code. It would no longer be possible to read call sites and be able to distinguish which ones might crash due to an uncaught error.</div><div class=""><br class=""></div><div class="">(There are exceptions to this rule. Ordinary arithmetic and array access are checked at runtime, and the default syntax is one that may crash.)</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">-- </div><div class="">Greg Parker <a href="mailto:gparker@apple.com" class="">gparker@apple.com</a> Runtime Wrangler</div><div class=""><br class=""></div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></body></html>