`negated` or `negatedValue` or `negatedBoolValue` looks good to me too. I think that it should be implemented on BooleanType because you do not want to consider whether it is Bool or DarwinBoolean or ObjCBool when just need a negated value.
I also understand your mixed feelings because negation operator is so familiar to every developer. I suggest you to try using negation property on real code for a bit. Code readability is a very important. But in my opinion pipelining can be more expressive in some cases. But this discussion is off topic. > 21 трав. 2016 р. о 19:49 Charlie Monroe <[email protected]> > написав(ла): > > 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] >> <mailto:[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
