I'm going to courteously disagree. The not operator belongs on the leading edge and not the trailing edge of the expression:
* One writes ~TruthValue, ¬TruthValue, "not TruthValue", etc. * One does not write TruthValue~, TruthValue¬, or "TruthValue not". 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. 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. -- E > On May 21, 2016, at 8:50 AM, Антон Миронов via swift-evolution > <[email protected]> wrote: > > 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: > > extension BooleanType { > var not: Bool { return !self.boolValue } > } > > This is code with negation operator: > return !self.lanes[position.y][currentLaneRange].contains(.Gap) > > 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. > > This is code with “not” property: > return self.lanes[position.y][currentLaneRange].contains(.Gap).not > > Now it is easy to spot the statement I am actually getting negation of. > 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. > > Thanks, > Anton Mironov > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
