`integers.all { $0.isEven }` reads like an alias of `filter` to me. The meaning
is ambiguous because the missing argument label can be filled in in different
ways -- some will read this as "all are even", and others will read it as "all
that are even".
I think that ambiguity should be avoided. Something along the lines of
`integers.allMatch { $0.isEven }` does just that and reads quite nicely in my
opinion. I also like `integers.containsOnly { $0.isEven }` a lot since it pairs
nicely with the existing `contains` method.
Jarod
On Apr 4, 2017, 02:16 -0700, David Rönnqvist via swift-evolution
<[email protected]>, wrote:
> I agree that `all(equal:)` and `all(match:)` are really good names for these
> methods (I could also consider `every`).
>
> In my understanding of the Swift API Design Guidelines, it’s good for a
> number of reasons:
>
> It omits needless words. It’s a sequence of Element, so explicitly mentioning
> “elements”, “members”, or “items" doesn’t add much.
>
> It strives for fluent usage when used with their argument labels. As Daniel
> Duan pointed out, these names roughly read read as:
>
> > things all match condition?
> > things all equal value?
>
> Without the argument label it’s not as clear what it does, but other
> functions have a similar problems when used without argument labels. For
> example,
>
> xs.prefix { $0 > 5 }
> xs.drop { $0 > 5 }
> xs.index { $0 > 5 }
>
> It uses terminology well, if `all` is accepted as a term of art. It is at
> least a common term in other languages for this functionality.
>
> However, one area where it doesn’t hold as well (ignoring any term of art
> argument) is that Boolean methods [...] should read as assertions […] when
> the use is nonmutating. Here I kind of like the `are` prefix, similar to how
> `empty` has an `is` prefix (isEmpty). In this case I would also like to see
> the labels change for a more fluent usage: `areAll(equalTo:)` and
> `areAll(matching:)`.
>
>
> > On 3 Apr 2017, at 10:29, Daniel Duan via swift-evolution
> > <[email protected]> wrote:
> >
> > I want to retract my nitpickings on argument labels; `all(equal:)` and
> > `all(match:)` are the best names for these methods.
> >
> > things all match condition?
> > things all equal value?
> >
> > If we accept `all` as a term of art (which I think we should), along with
> > these labels the use site are very readable!
> >
> > > On Mar 31, 2017, at 6:38 PM, Daniel Duan via swift-evolution
> > > <[email protected]> wrote:
> > >
> > > nit: should these names be `all(matching)`/`all(equalTo)` per API Design
> > > Guidelines?
> > > > On Mar 31, 2017, at 8:28 AM, Ben Cohen via swift-evolution
> > > > <[email protected]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > A short proposal for you as part of the algorithms theme. Hopefully
> > > > non-controversial, aside from the naming of the method and arguments,
> > > > about which controversy abounds. Online copy here:
> > > > https://github.com/airspeedswift/swift-evolution/blob/9a778e904c9be8a3692edd19bb757b23c54aacbe/proposals/0162-all-algorithm.md
> > > >
> > > >
> > > > Add an all algorithm to Sequence
> > > >
> > > > • Proposal: SE-NNNN
> > > > • Authors: Ben Cohen
> > > > • Review Manager: TBD
> > > > • Status: Awaiting review
> > > >
> > > > Introduction
> > > > It is common to want to confirm that every element of a sequence equals
> > > > a value, or matches a certain criteria. Many implementations of this
> > > > can be found in use on github. This proposal adds such a method to
> > > > Sequence.
> > > > Motivation
> > > > You can achieve this in Swift 3 with contains by negating both the
> > > > criteria and the result:
> > > >
> > > > // every element is 9
> > > > !nums.contains { $0 != 9 }
> > > > // every element is odd
> > > > !nums.contains { !isOdd($0) }
> > > > but these are a readability nightmare. Additionally, developers may not
> > > > make the leap to realize contains can be used this way, so may
> > > > hand-roll their own for loop, which could be buggy, or compose other
> > > > inefficient alternatives:
> > > >
> > > > // misses opportunity to bail early
> > > > nums.reduce(true) { $0.0 && $0.1 == 9 }
> > > > // the most straw-man travesty I could think of...
> > > > Set(nums).count == 1 && Set(nums).first == 9
> > > > Proposed solution
> > > > Introduce two algorithms on Sequence which test every element and
> > > > return true if they match:
> > > >
> > > > nums.all(equal: 9)
> > > > nums.all(match: isOdd)
> > > > Detailed design
> > > > Add the following extensions to Sequence:
> > > >
> > > > extension Sequence {
> > > > /// Returns a Boolean value indicating whether every element of the
> > > > sequence
> > > > /// satisfies the given predicate.
> > > > func all(match criteria: (Iterator.Element) throws -> Bool) rethrows ->
> > > > Bool
> > > > }
> > > >
> > > > extension Sequence where Iterator.Element: Equatable {
> > > > /// Returns a Boolean value indicating whether every element of the
> > > > sequence
> > > > /// equals the given element.
> > > > func all(equal element: Iterator.Element) -> Bool
> > > > }
> > > > Source compatibility
> > > > This change is purely additive so has no source compatibility
> > > > consequences.
> > > > Effect on ABI stability
> > > > This change is purely additive so has no ABI stability consequences.
> > > > Effect on API resilience
> > > > This change is purely additive so has no API resilience consequences.
> > > > Alternatives considered
> > > > Not adding it.
> > > > _______________________________________________
> > > > 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
>
> _______________________________________________
> 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
