This would be a minimal, but worthwhile inclusion to the stdlib that will benefit a large number of developers.
Yes, I've wanted this addition for a while since this is a frequent enough operation and the lack of it has been rather annoying. (I tend to go with the .reduce route in my own code to avoid creating the intermediate array)
This kind of additive change matches other similar types of proposals.
Read through the proposal and kept up with the associated pitch. The API is clean and easy/intuitive to find. This inclusion will definitely simplify some of my own projects.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes
Does this proposal fit well with the feel and direction of Swift?
Yes
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Yes. It is as straightforward/efficient as I've seen.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read the proposal and have followed discussion here and there.
let review = [
"What is your evaluation of the proposal?":
"""
✅ This is a useful building-block operation that I \
frequently have to write myself. It should absolutely \
be a part of the standard library.
""",
"Is the problem being addressed significant enough to warrant a change to Swift?":
"""
✅ As the proposal describes, the naive approach \
is needlessly inefficient and can be unclear \
at the point of use.
""",
"Does this proposal fit well with the feel and direction of Swift?":
"""
✅ The naming is intuitive and matches other `Sequence` \
operations, such as `first(where:)` and `lastIndex(where:)`.
""",
"If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?":
"""
✅ It matches the power & expressiveness of Ruby's `count`, \
which is the closest parallel that I've used.
"""
]
let score = review.values.count(where: { $0.contains("✅") })
This proposal seems like a worthwhile and useful change to Swift. It seems like it could be useful in a wide variety of situations, including ones relevant to my own development work. Furthermore, this change simplifies syntax, expanding upon the existing ideas of the language. I gave the proposal a thorough read-through.
+1. The count(where:) method is fairly straight-forward to write yourself but in my experience people often don't identify that their filter + count approach is sub-optimal (both in readability and efficiency). Many codebases will benefit from this addition to the standard library.
I'd also like to see the addition of count(of:) which the proposal briefly mentions – it's certainly not as widely applicable as count(where:), but I've had use cases for it. count(of: x) is a lot more readable than count(where: { $0 == x }) and it would fit well in the standard library alongside the Equatable counterparts of firstIndex(where:), contains(where:), split(whereSeparator:), etc.
+1. I don't have much to add beyond what other folks have already said. This is a worthwhile addition, and the proposal illustrates incredibly well how trying to piece this together with existing constructs leads to either less readable or less efficient code. That's evidence enough that count(where:) should be among the fundamental building blocks that sequences/collections in stdlib should provide.
Is the problem being addressed significant enough to warrant a change to Swift?
A tiny additive change: Yes.
Does this proposal fit well with the feel and direction of Swift?
Yes
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Yes. It is one of the best I've seen.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Read the proposal and followed the discussion.
+1. Simple, useful, enhances readability, likely to improve performance for many.
As ABI stability lands, I hope that we can be less shy about letting the standard library grow to include conveniences and ergonomic improvements like this. There's a point where conveniences go too far, but Swift is still well shy of it.
+1 for all the reasons that were stated by others above.
On a meta level, I'm slightly worries that such minimal, common sense and uncontroversial extensions to Swift have to go through the disproportionately heavyweight Swift Evolution process. See exhibit B.
It contains a relatively simple algorithm, but is common enough as evident by the previous replies. I have written the less general variant count(of:) many times before. (Which, if this proposal gets accepted, can be rewritten as count { $0 == ... }).
It will make code more readable and feels like a natural extension of count and filter(where:) and therefore fits well with the feel and direction of Swift.
It is flexible enough through its use of a closure predicate.
It is tricky to get right, as described in the proposal's motivation section.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?