<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=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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 class=""></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 class=""></div><div>func addObject(object: AnyObject?)</div><div>func objectAtIndex(index: Int) -> AnyObject?</div><div><br class=""></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 class=""></div><div>In case of addObject, would you just silently ignore the nil, or would you crash as NSArray would?</div><div><br class=""></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 class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><div class="">
<div style="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; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Saagar Jha<br class=""><br class=""><br class=""></div>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 20, 2016, at 21:10, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@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 Jul 20, 2016, at 5:24 PM, Saagar Jha <<a href="mailto:saagarjha28@gmail.com" class="">saagarjha28@gmail.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="">Sorry for the last email…I didn’t see your response.<div class=""><br class=""></div><div class="">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 class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div></div>Because an override of an unaudited method has to *use* the parameters.<div class=""><br class=""></div><div class="">-Chris</div></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>