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

[Robert Bennett]

That's a good point, but now you've got me wondering whether *those* overloads are necessary either :/

I suppose one reason overloads make more sense to me in the case of index and contains is because those two operations are in fact frequently used to look for a particular element by its value, so the overloads are truly convenient (if not strictly necessary). Those operations are also common in other languages -- some languages don't even have an index(where:), instead opting to search for true in the result of lazily mapping the predicate over the array. There is some value to not eschewing convention there.

However, I think all(equal:) *is* an unnecessary convenience because I don't think that it is a common operation to check that an array only contains a single value (arr.all(equal: 9)? Really? Why would we have an array of all 9's?), except when checking that a Boolean array is all true or all false. But in this case one likely could have used the all(where:) version on another, non-Boolean array in the first place. I can't think of an instance where I would store a Boolean array for its own sake; Boolean arrays usually represent a condition on some array that we *really* care about. In the event that someone is using a "genuine" Boolean array, arr.all(equal: true) is no nicer than arr.all { $0 }, so we might as well keep the namespace a bit cleaner and go with just all(where:).

> On Mar 31, 2017, at 8:11 PM, Ben Cohen <ben_cohen at apple.com> wrote:
> 
> 
>> On Mar 31, 2017, at 4:20 PM, Robert Bennett via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Sorry, despite the curt tone of my initial post, I think this is overall a great idea. Ben, thanks for drafting the proposal.
>> 
> 
> No worries!
> 
>>> On Mar 31, 2017, at 6:12 PM, Ricardo Parada <rparada at mac.com> wrote:
>>> 
>>> I agree. 
>>> 
>>>> On Mar 31, 2017, at 5:32 PM, Robert Bennett via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> I'm don't think we need all(equal:).
>>>> 1) For a host of reasons, having a single signature for a function name is better than having multiple signatures when the single signature is capable enough.
>>>> 2) A list containing a single distinct element is not a special enough case to check for to warrant its own function signature.
>>>> 
>>>> all(equal:) can be replicated easily enough with nums.all { $0 == 9 }. Unlike all(equals:), this is extendible to non-Equatable types with equatable members.
> 
> It is a pretty well-established practice in the standard library at this point to overload like this, with a version relying on protocol conformance, and a more general version that takes a closure and doesn't. So sort() relies on Comparable, but sort(by:) doesn’t, contains(_:) and index(of:) rely on Equatable, but contains(where:) and index(where:) are more general versions that take a closure. There are several other similar examples. This proposal follows along similar lines.
> 
>>>> _______________________________________________
>>>> 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
>