[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