Thanks for all the feedback everyone, I just submitted a short proposal as
a PR: https://github.com/apple/swift-evolution/pull/782
On Fri, Jan 12, 2018 at 11:34 PM, Anders Kierulf via swift-evolution <
swift-evolution@swift.org> wrote:
> I also avoid using ! for negation when possible, and `toggle` or `invert`
> will be helpful, but in many cases I think the negative case is better
> expressed directly. For example, I find that using `nonEmpty` instead of
> !isEmpty makes the code easier to read:
>
> extension String {
> var nonEmpty: Bool { return !self.isEmpty }
> }
>
> if !string.isEmpty { … }
>
> if string.isEmpty.inverted() { … }
>
> if string.nonEmpty { … }
>
> For the case of `contains`, maybe define `lacks`?
>
> if !items.contains(item) { ... }
>
> if items.contains(item).inverted() { ... }
>
> if items.lacks(item) { ... }
>
> Anders Kierulf
>
> > On Jan 12, 2018, at 12:54 PM, Alejandro Martinez via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I wouldn't go as far as to ask to fade out ! but in all my code I end
> > up doing == false just for readability. That ! knows who to hide
> > himself too well :P
> >
> > On Fri, Jan 12, 2018 at 10:13 AM, Adrian Zubarev via swift-evolution
> > <swift-evolution@swift.org> wrote:
> >> I’m not sure if this would be considered or not, but I would like if the
> >> negation operator `!` would fade out.
> >>
> >> If this is ever going to a review then I’d suggest that we add a pair of
> >> functions, one mutating and the other non-mutating.
> >>
> >> extension Bool {
> >> mutating func invert() {
> >> self = !self
> >> }
> >>
> >> func inverted() {
> >> return !self
> >> }
> >> }
> >>
> >> I’d rather use `inverted` instead of `!` because of the readability this
> >> function provides.
> >>
> >> if !items.contains(item) { ... }
> >>
> >> if items.contains(item).inverted() { ... }
> >>
> >> ——
> >>
> >> I personally have some other extensions like:
> >>
> >> extension Bool {
> >> @discardableResult
> >> func whenTrue<T>(execute closure: () throws -> T) rethrows -> T? {
> >> if self { return try closure() }
> >> return nil
> >> }
> >>
> >> @discardableResult
> >> func whenFalse<T>(execute closure: () throws -> T) rethrows -> T? {
> >> if !self { return try closure() }
> >> return nil
> >> }
> >> }
> >>
> >> But this is more a personal preference.
> >>
> >> ——
> >>
> >> That said, if the community is fine with the `invert/inverted` pair
> then I’d
> >> say go for it ;)
> >>
> >> Am 12. Januar 2018 um 09:14:22, Nate Cook via swift-evolution
> >> (swift-evolution@swift.org) schrieb:
> >>
> >>
> >> On Jan 12, 2018, at 12:15 AM, Chris Eidhof via swift-evolution
> >> <swift-evolution@swift.org> wrote:
> >>
> >> Hey SE!
> >>
> >> When we have a bunch of nested structs:
> >>
> >> struct Sample {
> >> var bar: Bar
> >> }
> >>
> >> struct Bar {
> >> var show: Bool
> >> }
> >>
> >> var foo = Sample(bar: Bar(show: false))
> >>
> >> It can be repetitive to toggle a deeply nested boolean:
> >>
> >> foo.bar.show = !foo.bar.show // duplication
> >>
> >> I sometimes add a `toggle` extension on `Bool`
> >>
> >> extension Bool {
> >> mutating func toggle() {
> >> self = !self
> >> }
> >> }
> >>
> >> This allows you to write the same code without duplication, and makes
> the
> >> intent clearer:
> >>
> >> foo.bar.show.toggle()
> >>
> >>
> >> I like it!
> >>
> >> In other languages, I don't think the `toggle` would make as much
> sense, but
> >> the mutable self makes this very useful.
> >>
> >> After I posted it on Twitter, it turns out I'm not the only one:
> >> https://twitter.com/PublicExtension/status/730434956376346624
> >>
> >> I would have gone straight to a proposal, but I think we can do some
> >> bikeshedding about the name of `toggle`?
> >>
> >>
> >> Another verb that could work is `invert`.
> >>
> >> The `!` operator that does this is the negation operator, but I think
> >> `negate` could sound to some like "make this false" rather than
> toggling.
> >>
> >> Nate
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >>
> >
> >
> >
> > --
> > Alejandro Martinez
> > http://alejandromp.com
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
--
Chris Eidhof
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
