<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">All I meant is that it’s usage should fade, which is my personal opinion. That said, I didn’t meant to say it should be removed or something. ;)</div> <br> <div id="bloop_sign_1515786900351390720" class="bloop_sign"></div> <br><p class="airmail_on">Am 12. Januar 2018 um 20:54:16, Alejandro Martinez (<a href="mailto:alexito4@gmail.com">alexito4@gmail.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>I wouldn't go as far as to ask to fade out ! but in all my code I end
<br>up doing == false just for readability. That ! knows who to hide
<br>himself too well :P
<br>
<br>On Fri, Jan 12, 2018 at 10:13 AM, Adrian Zubarev via swift-evolution
<br><swift-evolution@swift.org> wrote:
<br>> I’m not sure if this would be considered or not, but I would like if the
<br>> negation operator `!` would fade out.
<br>>
<br>> If this is ever going to a review then I’d suggest that we add a pair of
<br>> functions, one mutating and the other non-mutating.
<br>>
<br>> extension Bool {
<br>> mutating func invert() {
<br>> self = !self
<br>> }
<br>>
<br>> func inverted() {
<br>> return !self
<br>> }
<br>> }
<br>>
<br>> I’d rather use `inverted` instead of `!` because of the readability this
<br>> function provides.
<br>>
<br>> if !items.contains(item) { ... }
<br>>
<br>> if items.contains(item).inverted() { ... }
<br>>
<br>> ——
<br>>
<br>> I personally have some other extensions like:
<br>>
<br>> extension Bool {
<br>> @discardableResult
<br>> func whenTrue<T>(execute closure: () throws -> T) rethrows -> T? {
<br>> if self { return try closure() }
<br>> return nil
<br>> }
<br>>
<br>> @discardableResult
<br>> func whenFalse<T>(execute closure: () throws -> T) rethrows -> T? {
<br>> if !self { return try closure() }
<br>> return nil
<br>> }
<br>> }
<br>>
<br>> But this is more a personal preference.
<br>>
<br>> ——
<br>>
<br>> That said, if the community is fine with the `invert/inverted` pair then I’d
<br>> say go for it ;)
<br>>
<br>> Am 12. Januar 2018 um 09:14:22, Nate Cook via swift-evolution
<br>> (swift-evolution@swift.org) schrieb:
<br>>
<br>>
<br>> On Jan 12, 2018, at 12:15 AM, Chris Eidhof via swift-evolution
<br>> <swift-evolution@swift.org> wrote:
<br>>
<br>> Hey SE!
<br>>
<br>> When we have a bunch of nested structs:
<br>>
<br>> struct Sample {
<br>> var bar: Bar
<br>> }
<br>>
<br>> struct Bar {
<br>> var show: Bool
<br>> }
<br>>
<br>> var foo = Sample(bar: Bar(show: false))
<br>>
<br>> It can be repetitive to toggle a deeply nested boolean:
<br>>
<br>> foo.bar.show = !foo.bar.show // duplication
<br>>
<br>> I sometimes add a `toggle` extension on `Bool`
<br>>
<br>> extension Bool {
<br>> mutating func toggle() {
<br>> self = !self
<br>> }
<br>> }
<br>>
<br>> This allows you to write the same code without duplication, and makes the
<br>> intent clearer:
<br>>
<br>> foo.bar.show.toggle()
<br>>
<br>>
<br>> I like it!
<br>>
<br>> In other languages, I don't think the `toggle` would make as much sense, but
<br>> the mutable self makes this very useful.
<br>>
<br>> After I posted it on Twitter, it turns out I'm not the only one:
<br>> https://twitter.com/PublicExtension/status/730434956376346624
<br>>
<br>> I would have gone straight to a proposal, but I think we can do some
<br>> bikeshedding about the name of `toggle`?
<br>>
<br>>
<br>> Another verb that could work is `invert`.
<br>>
<br>> The `!` operator that does this is the negation operator, but I think
<br>> `negate` could sound to some like "make this false" rather than toggling.
<br>>
<br>> Nate
<br>> _______________________________________________
<br>> swift-evolution mailing list
<br>> swift-evolution@swift.org
<br>> https://lists.swift.org/mailman/listinfo/swift-evolution
<br>>
<br>>
<br>> _______________________________________________
<br>> swift-evolution mailing list
<br>> swift-evolution@swift.org
<br>> https://lists.swift.org/mailman/listinfo/swift-evolution
<br>>
<br>
<br>
<br>
<br>--
<br>Alejandro Martinez
<br>http://alejandromp.com
<br></div></div></span></blockquote></body></html>