<div dir="ltr">Ah, I understand now; that’s a good point.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 20, 2016 at 9:54 PM Charlie Monroe <<a href="mailto:charlie@charliemonroe.net">charlie@charliemonroe.net</a>> wrote:<br></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><blockquote type="cite"><div><div style="word-wrap:break-word">To use the parameters, the function would have to check for nil anyways, right (or risk a crash at runtime)? If the parameter is changed from an IUO to an Optional, the check for nil simply becomes a shadowing with guard.</div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>And what if the overridden method returns "T!"? It would become T? in the code, while the original API expects a non-nil value. This IMHO adds confusion to the language. As I've mentioned previously, these are examples that you'd get:</div><div><br></div><div>func addObject(object: AnyObject?)</div><div>func objectAtIndex(index: Int) -> AnyObject?</div><div><br></div><div>This is from NSArray, but if you had a similar un-audited API, then created your subclass of this, you'd get something semantically completely different and users of your API would assume you can pass nil to addObject and that objectAtIndex can return nil.</div><div><br></div><div>In case of addObject, would you just silently ignore the nil, or would you crash as NSArray would?</div><div><br></div><div>Yes, it's unexpected sometimes to find nil coming from these methods, or getting them as arguments, but it's just as unexpected as finding out that your app is crashing because it's accessing index out of bounds.</div><br><blockquote type="cite"><div></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div style="word-wrap:break-word"><div><br><div>
<div style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;word-wrap:break-word">Saagar Jha<br><br><br></div>
</div>
<br><div><blockquote type="cite"><div>On Jul 20, 2016, at 21:10, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:</div><br><div><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jul 20, 2016, at 5:24 PM, Saagar Jha <<a href="mailto:saagarjha28@gmail.com" target="_blank">saagarjha28@gmail.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">Sorry for the last email…I didn’t see your response.<div><br></div><div>I realize that disallowing IUOs in parameters (but not as properties) is inconsistent, but IUOs for properties make sense: they must be set during initialization, but sometimes this isn’t possible. IUOs make it possible to use the property just as any other non-Optional one, <b>provided the property is set before it is used</b> (see the proposal). This kind of guarantee doesn’t work for function parameters and return values. </div><div><br></div><div>As for IUOs for non-audited methods; why can’t they just all use Optional parameters? It should have the same behavior as before, since you can pass in both an Optional as well as a non-Optional even today.</div></div></div></blockquote><div><br></div></div>Because an override of an unaudited method has to *use* the parameters.<div><br></div><div>-Chris</div></div></div></blockquote></div><br></div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div>_______________________________________________<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/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></blockquote></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">-Saagar Jha</div></div>