[swift-evolution] [Pitch] Add an all algorithm to Sequence

Wed Apr 5 15:26:21 CDT 2017

On Apr 5, 2017, 13:21 -0700, Xiaodi Wu <xiaodi.wu at gmail.com>, wrote:

> On Wed, Apr 5, 2017 at 2:22 PM, Jarod Long via swift-evolution <swift-evolution at swift.org> wrote:
> > > `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.
> >
> > There is little to stop someone who might interpret "all are even" to mean "all that are even" also from interpreting "all match" to mean "all that match."
> >
> > The point of having that gigantic discussion on API guidelines in the past was to obviate these kinds of discussions. Does the proposed `all(equal:)` adhere to those guidelines? If so, then the presumption should be that it achieves the right balance of clarity, concision, readability, etc. If not, we ought to ask what we need to do to get it into compliance with the guidelines, or whether a term-of-art exception is called for.

I think "all that match" would be a far less reasonable and common interpretation, because if the phrase were to be shortened by removing "that", it would then be phrased as "all matching", not "all match".

I don't want to derail the discussion too much regarding the guidelines, but I'll say that I think it's unrealistic to expect them to eliminate the need to discuss naming. There's a lot of wiggle room within the guidelines, and I think it would be a mistake to hastily accept the first name we think of that doesn't blatantly violate them. We shouldn't spend be spending weeks upon weeks discussing each and every name, but we're well within a reasonable timeframe of discussion for this proposal 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 <swift-evolution at swift.org>, 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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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
> > > > > > > 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
> > > > >
> > > > > _______________________________________________
> > > > > 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
> > >
> > > _______________________________________________
> > > 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/20170405/906fbcb5/attachment.html>