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

[Jay Abbott]

>From a clarity at point of use point of view areAll is the best suggestion
so far. Even when other variables or methods aren’t named very well, it
suggests both the plural nature of the thing being operating on, and the
boolean nature of the return value, for example:

yourBase.areAll { $0.belong(to: us) }

It also tips the hat to all but without the confusing filter-like
expectations.
​

On Wed, 5 Apr 2017 at 23:45 Jonathan Hull via swift-evolution <
swift-evolution at swift.org> wrote:

> On that note: ‘containsOnly' is still my favorite by a wide margin.  I
> know it is longer than ‘all’, but it’s behavior is much clearer (especially
> for those of us who have never used or heard of ‘all’ in other languages),
> and it’s relationship with ‘contains’ is also very clear.
>
> Thanks,
> Jon
>
>
>
> On Apr 5, 2017, at 3:06 PM, Jarod Long via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I don't think an argument label is sufficient to satisfy the first
> fundamental API design guideline: "Clarity at the point of use is your most
> important goal."
>
> The argument label is not visible at the point of use when using trailing
> closure syntax, so it provides no additional clarity there. Moving the
> argument label into the base method name solves that problem and I think is
> a clear case of satisfying the second fundamental guideline: "Clarity is
> more important than brevity."
>
> Jarod
>
> On Apr 5, 2017, 14:51 -0700, Kevin Nattinger via swift-evolution <
> swift-evolution at swift.org>, wrote:
>
> I definitely think we should stick with `all` and an appropriate argument
> label. It’s a term of art and the label makes it perfectly clear what to
> expect.
> That said, `all(match)` and `all(equal)` sound to me like they expect an
> object to compare each against (func all(equal needle: Element))
> I suggest something like `all(pass:)`.
>
> On Apr 5, 2017, at 4:34 PM, Brandon Trussell via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I retract my gripes on the original names also.  The argument labels make
> the intent of the method clear.
>
> On Wed, Apr 5, 2017 at 11:23 AM, Thorsten Seitz via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> +1
>
> Am 03.04.2017 um 10:29 schrieb Daniel Duan via swift-evolution <
> swift-evolution at swift.org>:
>
> 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 <https://github.com/airspeedswift>
>    - 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
>
> _______________________________________________
> 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
>
>
>
>
> --
> Brandon
> _______________________________________________
> 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/d64ee598/attachment.html>