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
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
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.
What Xcode are you using?
It needed to be reverted, Require parameter names when referencing to functions - #77 by Ponyboy47 goes into more detail.
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
@rudedogg here a follow up thread that tries to solve the issue which blocked the accepted proposal:
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
?
In principle, yes.
Was the option to rename the method to filteredCount(where:)
considered? If yes, why did wasn't that option accepted?
I would suggest the name countEach(where:)
as a compromise.
Many renamings are possible, but ideally we'll just fix the type checker issue =)
Well that works too.