<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="">On Mar 17, 2016, at 1:45 PM, Jed Lewison <<a href="mailto:jed.lewison@icloud.com" class="">jed.lewison@icloud.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=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 17, 2016, at 12:16 AM, Chris Willmore via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class="">To run with the example above, <font face="Menlo" class="">emailTextField</font> would have type <font face="Menlo" class="">UITextField?</font> but, because it’s an IUO declaration, it would still be usable in contexts that required non-optional <font face="Menlo" class="">UITextField</font>. What would change is that if you were to say, e.g.</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Menlo" class="">let textField = controller.emailTextField</font></div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">then <font face="Menlo" class="">textField </font>would have type <font face="Menlo" class="">UITextField?</font>. But you could still say</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class=""><font face="Menlo" class="">formView.addSubview(controller.emailTextField)</font></div></div></blockquote></div></div></blockquote><div class=""><br class=""></div><div class="">For this scenario, would you be able to implicitly force-unwrap when a non-optional is not required, like:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="font-family: Monaco; white-space: pre;"> </span><font face="Menlo" class="">controller.emailTextField.minimumFontSize = 12</font></div><div class=""><br class=""></div><div class="">Or would you have to say:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="font-family: Monaco; white-space: pre;"> </span><font face="Menlo" class="">controller.emailTextField?.minimumFontSize = 12</font></div></div></div></div></blockquote><div><br class=""></div>The first one. The type-checked expression would force <span style="font-family: Menlo;" class="">controller.emailTextField</span>.</div><div><br class=""></div><div><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="">If the former, would <font face="Menlo" class="">fontSize</font> be an <font face="Menlo" class="">Optional<CGFloat></font> or a <font face="Menlo" class="">CGFloat</font> (non-optional)?</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span><font face="Monaco" class="">let fontSize = </font><span style="font-family: Monaco;" class="">controller.emailTextField.minimumFontSize</span></div></div></div></blockquote><div><br class=""></div>It would be a (non-optional) <font face="Menlo" class="">CGFloat</font>. Neither of these is different from current IUO behavior.</div><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="">As a user, I’m not sure which I’d expect. Given the behavior of <font face="Menlo" class="">let textField = controller.emailTextField</font>, it seems like i’d expect <font face="Menlo" class="">fontSize</font> to be an <font face="Menlo" class="">Optional<CGFloat></font>. Then again, if I’m allowed to implicitly unwrap emailTextField, it also doesn’t make any sense for fontSize to be an <font face="Menlo" class="">Optional</font>.</div></div></div></blockquote><div><br class=""></div><div>Yes, this is a little weird. But any attempt to remove the IUO type from the Swift type system, without removing the notion of IUOs entirely, runs into this sort of substitution-principle violation. It is not possible to pull an IUO sub-expression of an expression out into a temporary variable and have it type-check the same way without inferring the intermediate variable as IUO as well, a behavior that we explicitly wish to avoid.</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="">(I’m assuming that there would not be a circumstance where the IUO-ableness of the value would be preserved.)</div></div></div></blockquote><div><br class=""></div>The variable that the value is bound to could be explicitly marked as IUO. Otherwise, you’re correct.</div><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="">On a different note: As a general rule, I’m +1_000_000 on anything that makes IUO and force-unwrapping less common, so anything with the subject “Abolish IUO Type" makes me smile.</div></div></div></blockquote></div><br class=""><div class="">I’m glad we both feel that way!</div><div class="">— Chris Willmore</div></body></html>