Hey Swifters! I am looking for some feedback on the proper place to put this:
I made a thing to use KeyPaths to try and make creating predicates at least less Stringly-typed. I realize this has been proposed, in various fashions before:
Kuery, where I got the idea for most of this implementation, which led to
SR-5220 that's been sitting around for a while, and a
The key difference (as I see it) with what I've tried to pull together here is that I'm not trying to do operator overloading or create an additional Predicate layer for Swift on top of NSPredicate that could then be supported cross-platform - just make it easier to use NSPredicate in a way that is a) Type-safe and b) Avoids having to hard-code strings.
My bottom-line question: What is the best way to suggest Swift API improvements with possible sample code for Apple-owned APIs? Is it:
a) Radar
b) Swift Bugs
c) Swift Evolution
I think not c) since it's not purely Swift related (but change my mind if you disagree), but it'd be something I'd love to see be made easier across the board. It's a specifically Swift-related enhancement request rather than anything that has to do with the underlying API itself, so I'm not sure whether a) or b) makes more sense.
I think the only correct place for suggestions for Apple owned things, including the various wrappers around Apple APIs, is through filing a radar suggestion.
It's fairly difficult to do that effectively, because the broader community doesn't have much visibility into future plans for the frameworks and libraries that are being wrapped.
That said, you could develop and test small suggested changes against the open source tree and put them on GitHub and then reference them in radars. It's not perfect, and I would gently discourage doing lots of work on a branch like this, but for smaller improvements it's likely to work OK, at least with some components.
As the others on this thread have noted, unfortunately working on Foundation means threading the needle of a number of requirements:
We absolutely want your feedback and your input. That can take the form of bug reports, but we want to hear you in whatever form helps you most.
The bar for Foundation API changes is pretty high. The history of the Foundation framework is measured in decades and we want new changes to stand the test of time on that magnitude.
We don't quite have an Evolution process for Foundation. Part of what we do requires an extensive internal review process, and part of it means fitting what we do with future plans. But we do want to make sure your input isn't lost.
To this end: if you have a proposal for a new API or feedback on an existing one, I encourage you to start a new topic in the Core Libraries category with the foundation-pitch tag — we will try and respond to discuss and refine your proposal, and figure out what the consensus is.
