Add an all algorithm to Sequence

Evolution Pitches
63

Disagree. As Nevin reminded us, Swift Evolution is not a democracy, and naming isn't a popularity contest.

We have a set of naming guidelines, and the goal is to find the name that best reflects those guidelines and most clearly expresses the desired meaning. We can reason about this in the forum, explaining why we think one name reflects such objectives better than another, but the fact that many people prefer something doesn't help explain why it's better or even help us to determine whether or not it is.

4 Likes
64

And the bike shedding has begun. :)

1 Like
65

Maybe it should be put up as a proposal and if we donā€™t agree with the first draft letā€™s iterate on it to get to a better name. Putting up a proposal will help move it forward. I think we all agree on a least adding the functionality.

66

But there are multiple variants already proposed already that fit into the guidelines. Picking among them with a vote makes perfect sense.

67

The question is which one best fits the guidelines. The Swift Evolution community is not even close to being representative of the broader community of Swift users; there is no validity in having a vote.

Whoever writes the proposal gets to pick what they think is the best, and if no others are superior, then the proposal would be approved as written.

3 Likes
68

Since we're going to bikeshed again, I might as well contribute a new thought:

All other things being equal, a name that has some resemblance to the name of analogous methods in other languages is better than one that is completely novel. There's a lot to be said for familiarity. Many languages use words such as all, each, etc. in the name for this proposed method.

It occurs to me that we already have a precedent in Swift. There's already a method which uses one of the common words above, that causes each element to be used in turn as the argument for a custom function: forEach.

Therefore, I think we have a possibly good candidate name: isEach.

69

Do we in general expect / encourage people to give singular or plural names to sequence-type variables?

70

It looked a bit weird to me at first as well, but if you think about it, it makes sense: isEach(even), isEach(prime) vs areEach(odd) which doesn't sound as nice.

71

I would imagine it's whatever makes the most sense in idiomatic English.

72

Well that depends on whether or not you are using its subscript. :-)

73

That reads like obfuscation.

1 Like
74

Except that, if the predicates were named idiomatically, these would be isEach(isEven), isEach(isPrime), and isEach(isOdd). That's not so great.

75

What's the "test that none are x" counterpart to isEach?

76

I really like containsOnly! Itā€™s behavior is clear to anyone reading it (who knows what contains does). Clear and simple. All of the other things I have heard are a bit surprising/ambiguous to me...

Not sure if containsNone is really needed (as opposed to just !contains or contains().isFalse), but I wouldnā€™t vote against it because of it. I donā€™t feel strongly either way. I donā€™t like containsNo and would much rather just use containsNone across the board.

4 Likes
77

I think the discoverability of the new functions are paramount. Thatā€™s why Iā€™m quite worried about the each variants. My ā€œvoteā€ goes for:

array.containsOnly(5)
array.containsOnly(where: { $0 % 2 == 0 })
7 Likes
78

I agree with @hartbit. The negative version is unnecessary: it's easily achieved by through a predicate closure, and it's too hard to name anyway.

79

That is an excellent point, and I think it effectively precludes the use ā€œisā€ and ā€œareā€. Furthermore, whatever spelling we choose needs to read well both when called on a variable as well as when called on self inside an extension.

The main candidates appear to be containsOnly and all. The former is more verbose and explanatory, whereas the latter is more concise and an existing term of art. Either one would be fine by me.

1 Like
80

as a native english speaker ā€œnumbers.isEach(5)ā€ sounds really really weird. strongly prefer ā€œareAllā€ or something like that

1 Like
81

I didn't mean my response as an endorsement of isEach, rather, it was simply a defense of it against areEach.

82

So, I still think a negative is worth including, just for completeness sake. Many languages provide all 3, and as discussed in the "toggle() on Bool" thread, many of us prefer to make these statements more explicit than the ! operator. The argument that it is trivial also applies to "all".

So while neither of these functions are absolutely necessary, I think if we have "all", it is entirely reasonable to also want "none". The only question is finding a name - which is difficult, for sure, but I think we already have good options.

For me, the 2 leading naming options are:

  1. Plain-English. Has a certain appeal in your complex logic flows.
- contains(_:), contains(where:)
- onlyContains(_:), onlyContains(where:)
- doesNotContain(_:), doesNotContain(where:)
  1. Common prefix. Unbeatable discoverability.
- contains(_:), contains(where:)
- containsOnly(equalTo:), containsOnly(where:)
- containsNone(equalTo:), containsNone(where:)
1 Like