Or .isFalse  :)<br><div class="gmail_quote"><div dir="ltr">On Sat, May 21, 2016 at 10:22 AM Антон Миронов &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>`negated` or `negatedValue` or `negatedBoolValue` looks good to me too.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Code readability is a very important. But in my opinion pipelining can be more expressive in some cases. But this discussion is off topic.</div><div><br></div><br><div><blockquote type="cite"><div>21 трав. 2016 р. о 19:49 Charlie Monroe &lt;<a href="mailto:charlie@charliemonroe.net" target="_blank">charlie@charliemonroe.net</a>&gt; написав(ла):</div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><br><div><div style="word-wrap:break-word">If you have a pipeline like this, I&#39;d suggest to break it up into smaller segments also for the sake of readability...<div><br></div><div>The `not` var just doesn&#39;t seem right to me. Perhaps negatedValue? negatedBoolValue, since BooleanType has boolValue?</div><div><br></div><div>Question is whether this should be implemented on BooleanType or directly on Bool.</div><div><br></div><div>But I still have mixed feelings about this.</div><div><br></div><div>Charlie<br><div>
<br><div><blockquote type="cite"><div>On May 21, 2016, at 5:42 PM, Антон Миронов &lt;<a href="mailto:antonvmironov@gmail.com" target="_blank">antonvmironov@gmail.com</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word"><div>Good point. In such a case it would be more rational to have “not&quot; as func not(value Bool) -&gt; Bool { … } . But I am not a fun of such solution either.</div><div>You see, in swift, there is a lot of code that looks like:</div><div><br></div><div>let newValue = rawValue</div><div><span style="white-space:pre-wrap">        </span>.transformA(arg1) { ... }</div><div><span style="white-space:pre-wrap">        </span>.transformB(arg2) { ... }</div><div><span style="white-space:pre-wrap">        </span>.transformC(arg3) { ... }</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite"><div>21 трав. 2016 р. о 17:59 Charlie Monroe &lt;<a href="mailto:charlie@charliemonroe.net" target="_blank">charlie@charliemonroe.net</a>&gt; написав(ла):</div><br><div><div style="word-wrap:break-word"><div>This would make sense as an operator (or actually it would have to be a keywod):</div><div><br></div><div>return not self.lanes[...].contains(.Gap)</div><div><br></div><div>Or if you don&#39;t mind having { } around the expression it could be defined as a function:</div><div><br></div><div>func not(@noescape block: (Void) -&gt; Bool) rethrows -&gt; Bool { return !block() }</div><div><br></div><div>Then you can have</div><div><br></div><div>return not { self.lanes[...].contains(.Gap) }</div><div><br></div><div>But I am personally not a fan of this.</div><div><br></div><div>Charlie</div><br><div><blockquote type="cite"><div>On May 21, 2016, at 4:50 PM, Антон Миронов via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div style="word-wrap:break-word">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:<div><br></div><div>extension BooleanType {</div><div><span style="white-space:pre-wrap">        </span>var not: Bool { return !self.boolValue }</div><div>}<br><div><div><br></div><div>This is code with negation operator:</div><div><span style="white-space:pre-wrap">        </span>return !self.lanes[position.y][currentLaneRange].contains(.Gap)</div></div></div><div><div><div><br></div><div>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.</div><div><br></div><div>This is code with “not” property:</div><div><span style="white-space:pre-wrap">        </span>return self.lanes[position.y][currentLaneRange].contains(.Gap).not</div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><br></div></blockquote><div><div>Now it is easy to spot the statement I am actually getting negation of.</div><div>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.</div><div><br></div><div>Thanks,</div><div>Anton Mironov</div></div><div><br></div></div>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote></div><br></div></div></blockquote></div><br></div></div></div></div></blockquote></div></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>