[Pitch] Add an all algorithm to Sequence


#1

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.


(Ricardo Parada) #2

I agree.

···

On Mar 31, 2017, at 5:32 PM, Robert Bennett via swift-evolution <swift-evolution@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


#3

Sorry, despite the curt tone of my initial post, I think this is overall a great idea. Ben, thanks for drafting the proposal.

···

On Mar 31, 2017, at 6:12 PM, Ricardo Parada <rparada@mac.com> wrote:

I agree.

On Mar 31, 2017, at 5:32 PM, Robert Bennett via swift-evolution <swift-evolution@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Ben Cohen) #4

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!

I agree.

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(_:slight_smile: 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.

···

On Mar 31, 2017, at 4:20 PM, Robert Bennett via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 31, 2017, at 6:12 PM, Ricardo Parada <rparada@mac.com> wrote:

On Mar 31, 2017, at 5:32 PM, Robert Bennett via swift-evolution <swift-evolution@swift.org> wrote:

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


#5

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

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@apple.com> wrote:

On Mar 31, 2017, at 4:20 PM, Robert Bennett via swift-evolution <swift-evolution@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@mac.com> wrote:

I agree.

On Mar 31, 2017, at 5:32 PM, Robert Bennett via swift-evolution <swift-evolution@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(_:slight_smile: 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution