[swift-evolution] [Proposal] Add property for negation to Bool

[Jacob Bandes-Storch]

Or .isFalse :)
On Sat, May 21, 2016 at 10:22 AM Антон Миронов <swift-evolution at swift.org>
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 <charlie at charliemonroe.net>
> написав(ла):
>
>
> 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, Антон Миронов <antonvmironov at gmail.com>
> 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 <charlie at charliemonroe.net>
> написав(ла):
>
> 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 <
> swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160521/124effbc/attachment.html>