<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 class="">I'm going to courteously disagree. The not operator belongs on the leading edge and not the trailing edge of the expression:</div><div class=""><br class=""></div><div class="">* One writes ~TruthValue, ¬TruthValue, "not TruthValue", etc. </div><div class="">* One does not write TruthValue~, TruthValue¬, or "TruthValue not".</div><div class=""><br class=""></div><div class="">Reading code under the current system creates phrases like "if-not expression", naturally conjoining "if not". Under your proposed system, it reads as "if expression not" or "if expression negated truth value". This places a higher cognitive burden on the person reading the code and delays recognition that an expression should be understood in its inverse form. I think it's *more* likely a code reader would miss the intent in scanning than they would miss the leading exclamation point which, although small, is common and often used. As for using a property, such as ".not", ".negativeTruthValue", etc., although it makes the operation bigger and more noticeable, it does so in the wrong place, and inelegantly.</div><div class=""><br class=""></div><div class="">I wouldn't support introducing a `not` keyword as in `if not expression` as this does not feel "Swifty". It is neither concise, or more clear. All in all, this feels like a fix for something that isn't broken, and I cannot see any real world measurable benefit from changing the leading not operator. I believe the impact of the change would be larger than expected and to the detriment of the language.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On May 21, 2016, at 8:50 AM, Антон Миронов via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I found negation operator (!) the least detectable among the code. So I’ve decided to add property “not” to BooleanType (Swift 2.2) or Boolean on 3.0 with extension:<div class=""><br class=""></div><div class="">extension BooleanType {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var not: Bool { return !self.boolValue }</div><div class="">}<br class=""><div class=""><div class=""><br class=""></div><div class="">This is code with negation operator:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>return !self.lanes[position.y][currentLaneRange].contains(.Gap)</div></div></div><div class=""><div class=""><div class=""><br class=""></div><div class="">As I sad before negation operation is hard to spot. Moreover at first it looks like I’m trying to negate self for some reason.</div><div class=""><br class=""></div><div class="">This is code with “not” property:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>return self.lanes[position.y][currentLaneRange].contains(.Gap).not</div></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><br class=""></div></blockquote><div class=""><div class="">Now it is easy to spot the statement I am actually getting negation of.</div><div class="">On my experience negation operator can occasionally be missed while reading code. This happens less often with “not” property. So I’m proposing to add this property to standard library and prefer it in most cases.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Anton Mironov</div></div><div class=""><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>