<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I do not see a problem with the '!' negation operator. The case with forced unwrap + negation doesn't happen very often, (in my opinion) doesn't look that bad, and certainly isn't confusing. The other example cases also look pretty clear to me. Usage of '!' for implicit unwrapping vs its usage for negation is well-separated (one being prefix, the other postfix).&nbsp;</div><div class=""><br class=""></div><div class="">I *do* see negative effects of removing it: ! is part of virtually all programming languages currently in use, any decent programmer is accustomed to it and read it like 'not' in their head anyway. Removing would definitely confuse newcomers to the language.&nbsp;</div><div class=""><br class=""></div><div class="">/T</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">Op 15 dec. 2015, om 15:11 heeft Bruno Berisso via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; het volgende geschreven:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello,<div class=""><br class=""></div><div class="">I'm really used to negate logical expressions with this operator but it never feels confortable to me. If I need to negate some complex expression sometimes I prefer to write a temporal variable and then negate that with <b class="">!</b>&nbsp;because I fear than others, or myself, could overlook it and cause confusion.</div><div class=""><br class=""></div><div class="">Now that Swift use the same operator to force the unwrap of optional values it becomes even worse.</div><div class=""><br class=""></div><div class="">Consider this examples:</div><div class=""><br class=""></div><div class="">if someOptionalValue != nil {</div><div class="">&nbsp; &nbsp; ...</div><div class="">&nbsp; &nbsp; if !(otherBoolValue &amp;&amp; someOptionalValue! &gt; 0) {</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; ...</div><div class="">&nbsp; &nbsp; }</div><div class="">}</div><div class=""><br class=""></div><div class="">Or even worse, what happen when negating Optional&lt;Bool&gt; values?</div><div class=""><br class=""></div><div class="">//Best case</div><div class="">if let value = optionalBool where !value {</div><div class="">&nbsp; &nbsp; ...</div><div class="">}</div><div class=""><br class=""></div><div class="">//Worse case</div><div class="">if !optionalBool! {</div><div class="">&nbsp; &nbsp; ...</div><div class="">}</div><div class=""><br class=""></div><div class="">Now what happen with this examples if we instead use a&nbsp;<b class="">not</b>&nbsp;operator:</div><div class=""><br class=""></div><div class=""><div class="">if someOptionalValue != nil {</div><div class="">&nbsp; &nbsp; ...</div><div class="">&nbsp; &nbsp; if not (otherBoolValue &amp;&amp; someOptionalValue! &gt; 0) {</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; ...</div><div class="">&nbsp; &nbsp; }</div><div class="">}</div><div class=""><br class=""></div><div class="">if let value = optionalBool where not value {</div><div class="">&nbsp; &nbsp; ...</div><div class="">}</div><div class=""><br class=""></div><div class="">if not optionalBool! {</div><div class="">&nbsp; &nbsp; ...</div><div class="">}</div></div><div class=""><br class=""></div><div class="">I'm not sure if <b class="">not</b>&nbsp;is the right path here but I really want to improve the <b class="">!</b>&nbsp;to something more clear at a glance and that doesn't have different behaviour depending where it appears in an expression.</div><div class=""><br class=""></div><div class="">Thanks,</div></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=YfJegnDVHFjciv1mJPW79zu0hcjAYJ-2BpFoOAdq9R1JeEOjfztgrLfgHW6sn5aMshXoS0-2Bdx8HaIimenujn57LDfIn36kp6-2FBhdn-2BD4yWX4PuyRW-2BL0zvrMFV3uIsSg94mtB4i0DxxdW-2FtSMoVCfkzZAHmBxW3xa8lFO9ZAJx9rp1lbZI3FQy2bOFD8N3wgCvNY4Vhe8W6TvtyMoTZRKWISh-2BL96o6JW3fTlebv8-2BvRk-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></body></html>