<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 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><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></body></html>