Good point. In such a case it would be more rational to have “not" as func
not(value Bool) -> Bool { … } . But I am not a fun of such solution either.
You see, in swift, there is a lot of code that looks like:
let newValue = rawValue
.transformA(arg1) { ... }
.transformB(arg2) { ... }
.transformC(arg3) { ... }
It looks as a pipeline of transformations to me and I consider negation as one
of those transformations. On the other hand negation operator totally breaks
this pipeline. I personally prefer a bit longer list of transformations rather
than list of transformations and negation operator as prefix to the list.
> 21 трав. 2016 р. о 17:59 Charlie Monroe <[email protected]>
> написав(ла):
>
> This would make sense as an operator (or actually it would have to be a
> keywod):
>
> return not self.lanes[...].contains(.Gap)
>
> Or if you don't mind having { } around the expression it could be defined as
> a function:
>
> func not(@noescape block: (Void) -> Bool) rethrows -> Bool { return !block() }
>
> Then you can have
>
> return not { self.lanes[...].contains(.Gap) }
>
> But I am personally not a fan of this.
>
> Charlie
>
>> On May 21, 2016, at 4:50 PM, Антон Миронов via swift-evolution
>> <[email protected] <mailto:[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] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
