<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On 8 Mar 2016, at 21:49, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class="">The more likely outcome is that people are going to wrap throwable initializers in factory methods returning optionals, and throw away whatever error returns.</div></div></blockquote><div><br class=""></div><div>I hope not, seeing as try? lets you explicitly ignore the error if you only need to know that an error occurred (vs what it actually was). The key difference here is that it’s explicit, and you have to choose how you’re going to handle it. This is one of the big arguments for error handling vs failable, as both model errors, but error handling forces you to be explicit about what you’re doing about them, even if it’s nothing.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">As for the sample code, there is absolutely nothing wrong with it IMO. The contract to me for 'asInt' reads "return an Int if an item exists at `index` and, if that item exists, it can be represented as an Int”.</div></div></blockquote><div><br class=""></div><div>That's an assumption; MyType actually expects to only contain valid numeric strings, and I’ve simply forgotten to add a force unwrap on the Int() initialiser, now suddenly my method is returning nil for indices that exist but were supplied incorrectly. With error handling I’m required to pick one of try, try? and try! to decide which suits my needs, in which case I’d put try!. The throws would also clarify that `nil` never indicates an error.</div><div><br class=""></div><div>That said, I just realised it’s a poor example because the method shouldn’t return nil if it’s given an invalid index, rather it shouldn’t be given invalid indices in the first place (this would be in keeping with other methods in Array for example), but it’s just an over simplified example to make the point; the possible nil return from the initialiser is accidental.</div><div><br class=""></div><blockquote type="cite" class=""><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" class=""><div class=""><span style="font-family:Menlo;font-size:11px;color:rgb(187,44,162)" class="">struct</span><span style="font-family:Menlo;font-size:11px" class=""> MyType {</span></div><div style="margin:0px;font-size:11px;font-family:Menlo" class=""> <span style="color:#bb2ca2" class="">let</span> elements:[<span style="color:#703daa" class="">String</span>]</div><div style="margin:0px;font-size:11px;font-family:Menlo;min-height:13px" class=""><br class=""></div><div style="margin:0px;font-size:11px;font-family:Menlo" class=""> <span style="color:#bb2ca2" class="">func</span> asInt(index:<font color="#703daa" class="">Array<String>.Index</font>) -> <span style="color:#703daa" class="">Int</span>? {</div><div style="margin:0px;font-size:11px;font-family:Menlo" class=""> <span style="color:#bb2ca2" class="">if</span> <span style="color:#bb2ca2" class="">self</span>.<span style="color:#4f8187" class="">elements</span>.<span style="color:#703daa" class="">indices</span>.<span style="color:#3d1d81" class="">contains</span>(index) {</div><div style="margin:0px;font-size:11px;font-family:Menlo" class=""> <span style="color:#bb2ca2" class="">return</span> <span style="color:#703daa" class="">Int</span>(<span style="color:#bb2ca2" class="">self</span>.<span style="color:#4f8187" class="">elements</span>[index])</div><div style="margin:0px;font-size:11px;font-family:Menlo" class=""> }</div><div style="margin:0px;font-size:11px;font-family:Menlo" class=""> <span style="color:#bb2ca2" class="">return</span> <span style="color:#bb2ca2" class="">nil</span></div><div style="margin:0px;font-size:11px;font-family:Menlo" class=""> }</div><div style="margin:0px;font-size:11px;font-family:Menlo" class="">}</div></div></blockquote></div></div></blockquote><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">I think it's instructional to look at how Dictionary<T?> works - if you try to extract an element you get a double optional. This isn't a type system bug, it's completely intentional. The internal optional indicates whether an extant element was Some or None, and the external optional indicates whether or not the element existed in the dictionary to begin with. If I were writing that `asInt` function and I really needed to make the distinction between "invalid index" and "not an integer string", I'd use either that same double optional pattern, or make the function throws. If I didn't care, I'd use the optional representation.</div></div></blockquote><br class=""></div><div>Double optional to me indicates a difference between a return value of “nothing” (didn’t exist) and “stored value was nil”, I’d be very wary about using that to replace errors.</div></body></html>