<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 &lt;<a href="mailto:charlie@charliemonroe.net">charlie@charliemonroe.net</a>&gt; 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 &quot;T!&quot;? 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&#39;ve mentioned previously, these are examples that you&#39;d get:</div><div><br></div><div>func addObject(object: AnyObject?)</div><div>func objectAtIndex(index: Int) -&gt; 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&#39;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&#39;s unexpected sometimes to find nil coming from these methods, or getting them as arguments, but it&#39;s just as unexpected as finding out that your app is crashing because it&#39;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 &lt;<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>&gt; 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 &lt;<a href="mailto:saagarjha28@gmail.com" target="_blank">saagarjha28@gmail.com</a>&gt; 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>