<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><blockquote type="cite" class=""><div class=""><span 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; float: none; display: inline !important;" 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.</span><br class="Apple-interchange-newline"></div></blockquote></div><br class=""><div class="">I'm more or less neutral towards the proposal, but to express my perception, one part seems similar to the use of "!" in variable declarations (like IB does):</div><div class="">It just makes force unwrapping (or, here: assuming that no error happened) the default, but leaves all other options intact.</div><div class=""><br class=""></div><div class="">But Afaics, force unwrapped variables are considered a bad practice that should be avoided (nearly) wherever possible…</div><div class=""><br class=""></div><div class="">The "try?-replacement" could be more useful for me: In my codebase, I have several throwing functions paired with computed properties (returning an Optional of the same type) that directly map to them, and at the call site, I usually don't care about the error.</div><div class=""><br class=""></div><div class="">I'm not sure if it's useful enough to justify new syntactic sugar for it, though — especially as I think it's not very intuitive.</div></body></html>