If you have a pipeline like this, I'd suggest to break it up into smaller segments also for the sake of readability...
The `not` var just doesn't seem right to me. Perhaps negatedValue? negatedBoolValue, since BooleanType has boolValue? Question is whether this should be implemented on BooleanType or directly on Bool. But I still have mixed feelings about this. Charlie > On May 21, 2016, at 5:42 PM, Антон Миронов <[email protected]> wrote: > > 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] >> <mailto:[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 >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
