Or .isFalse :) On Sat, May 21, 2016 at 10:22 AM Антон Миронов <[email protected]> wrote:
> `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]> > 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]> > написав(ла): > > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
