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

Ben Cohen ben_cohen at apple.com
Fri Mar 31 19:11:36 CDT 2017


> 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



More information about the swift-evolution mailing list