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]> 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
