# \[Pitch\] Swift Predicates

**URL:** <https://forums.swift.org/t/pitch-swift-predicates/62000>\
**Category:** Core Libraries\
**Tags:** foundation\
**Created:** [December 12, 2022, 9:43pm UTC](https://forums.swift.org/t/pitch-swift-predicates/62000 "2022-12-12T21:43:52Z")\
**Posts on this page:** 1\
**Showing post:** 35

<div class="post-metadata">

**Author:** ![hassila](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hassila/32/22647_2.png) [@hassila](https://forums.swift.org/u/hassila)\
**Post date:** [February 1, 2023, 7:55am UTC](https://forums.swift.org/t/pitch-swift-predicates/62000/35 "2023-02-01T07:55:22Z")

</div>

Thanks for the clarification @dgoldsmith (we missed `parse()` somehow, it was the missing piece for us - EDIT: in fact, looking at the pitch, I can't find it, perhaps it can be added to the Tree Walking section as an example? It would be clearer than `spotlightQuery` at least for us) - we've discussed the pitch with our team internally and overall we think it would be a great addition and definitely would make heavy use of this, looks really promising.

Our only remaining major concern (which obviously is hard to know from a pitch, but please view this as an open question) would as mentioned be performance (of `evaluate()` - specifically the use of keypaths, as even though [SE-061](https://github.com/apple/swift-evolution/blob/main/proposals/0161-key-paths.md) have the following note on performance:

> The performance of interacting with a property/subscript via KeyPaths should be close to the cost of calling the property directly.

There are a few references so far to (quite significant) performance issues with the current keypath implementation, e.g.:

[https://github.com/apple/swift/issues/51793](https://github.com/apple/swift/issues/51793)

and

> [@Runtime performance cost of key paths](https://forums.swift.org/t/runtime-performance-cost-of-key-paths/36095):
>
> Questions Is there an expectation that keypaths significantly slower than functions or straight access with a closure? If so, is there anyway to mitigate these discrepancies while still using keypaths? Context I'm noticing anywhere between an increased factor of 2-10+ when using keypaths as functions or using dynamic member lookup. Program 1: Key paths as functions import AppKit func arrayClosureTest(\_ size: UInt) { let xs = (0 ... size).map(String.init) let t0 = CACurrentMediaTi…

I understand the optimization of keypath handling is handled by a different set of priorities, I just wanted to point it out if there is anything that can be done to minimize that possible impact.

I guess it's only tangential to the pitch, but wanted to at least call it out as performance of `evaluate()` is critical to the usability of Predicates (at least for us) - and the pitch overall really looks great and we'd be super happy to use it (as long as performance is ok).

So, anyway - big +1 for the pitch overall.

---

_[View the full topic](https://forums.swift.org/t/pitch-swift-predicates/62000)._