[swift-evolution] [Proposal] Add property for negation to Bool

[Антон Миронов]

You are completely right about ¬TruthValue. Going further I would say that in math list of transform looks like this: 

	transformC(transformB(transformA(value)))

Negation operator fits perfectly in such notation. But since Swift 2 language moved to notation:

	value.transformA.transformB.transformC

This notation is inverse to the one we see in math. So in my opinion negation property fits in new Swift notation as another transformation appended to others.



I agree that negation operator looks better for “if !value” such as:

let containsEvenNumers = numbers.contains { ($0 % 2) == 0 }
if !containsEvenNumers {
	print(“No even numbers here")
}

Because in this case you directly negate “containsEvenNumers”. But in case:

func isEven(number: Int) -> Bool { return (number % 2) == 0 }

if !numbers.contains(isEven) {
	print(“No even numbers here")	
}

negation operator actually has higher cognitive burden to me. I have to remember about prefix when I’m just trying to read expression from left to right.

On the other hand, negation property that looks like consecutive transformation lets me read expression in one direction. And since I’m used to reading expressions to the end it is easy to notice negation at the end.

func isEven(number: Int) -> Bool { return (number % 2) == 0 }
if numbers.contains(isEven).not {
	print(“No even numbers here")	
}

Maybe this question goes too deep. Or maybe unidirectional instruction flow is not that important.

Thanks,
Anton Mironov

> 22 трав. 2016 р. о 04:14 Erica Sadun <erica at ericasadun.com> написав(ла):
> 
> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160522/3ce3e274/attachment.html>