[Accepted] SE-0220: count(where:)

[Chris_Lattner3 (Chris Lattner)]

SE-0220: count(where:) has been accepted .

Feedback on the proposal was extremely positive, and the proposal was accepted without modifications. Thank you to everyone who participated in the review!

-Chris

[rudedogg (Austin Rude)]

What happened with count(where:)? I'm confused because the implementation was merged in September 2018, but I can't seem to find it in the Swift changelog.md, or in Xcode.

[John_McCall]

What Xcode are you using?

[owenv (Owen Voorhees)]

It needed to be reverted, Require parameter names when referencing to functions - #77 by Ponyboy47 goes into more detail.

[rudedogg (Austin Rude)]

That's too bad! Thanks for the details. I know it probably won't fly, but I'd be okay with elementCount(where:) to fix the type checker ambiguity

More seriously, I wonder if this would still be an issue with Swift 5.1? I thought I heard some type checker changes had to (or are currently) being made to handle SwiftUI.

@John_McCall Xcode 11/Swift 5.1 FWIW

[DevAndArtist (Adrian Meister)]

@rudedogg here a follow up thread that tries to solve the issue which blocked the accepted proposal:

Require parameter names when referencing to functions

Hi everyone, Some of you may remember SE-0220, my proposal that added the count(where:) function to sequences. This proposal was ultimately accepted in time for Swift 5, but sadly had to be reverted because it was causing issues with the type checker. The issue was that when you reference count, in an expression like myArray.count * 5, you could be referring to the count property, with type Int, or the count(where:) function, which has type ((Element) -> Bool) -> Int, which you can refer to in…

[AlexanderM (Alexander Momchilov)]

I imagine a lot of uses for this would have the pattern

someCollection.count(where: someCondition) == someConstant

Is that something the compiler could be clever about, and add short-circuiting (i.e. no need to keep going, if you've already surpassed a count of someConstant?

[dabrahams (Dave Abrahams)]

In principle, yes.

[prathameshk (Prathamesh Kowarkar)]

Was the option to rename the method to filteredCount(where:) considered? If yes, why did wasn't that option accepted?

[BigZaphod (Sean Heber)]

I would suggest the name countEach(where:) as a compromise.

[scanon (Steve Canon)]

@BigZaphod

I would suggest the name countEach(where:) as a compromise.

Many renamings are possible, but ideally we'll just fix the type checker issue =)

[BigZaphod (Sean Heber)]

Well that works too.