> On 2 Apr 2017, at 02:56, Karl Wagner <[email protected]> wrote:
>
> struct UnaryPredicate<Parameter> {
> let evaluate: (Parameter) -> Bool
> }
> struct BinaryPredicate<Left, Right> {
> let evaluate: (Left, Right) -> Bool
> }
>
> extension KeyPath where Value: Equatable {
> func equals(_ value: Value) -> UnaryPredicate<Root> {
> return UnaryPredicate { $0[keyPath: self] == value }
> }
> func equals<KP: KeyPath>(_ other: KP) -> BinaryPredicate<Root, KP.Root>
> where KP.Value == Value {
> return BinaryPredicate { $0[keyPath: self] == $1[keyPath: other] }
> }
> }
>
> let isDog = #keypath(Pet, .type).equals(.dog) // UnaryPredicate<Pet>
> if isDog.evaluate(somePet) {
> print(“It’s a dog”)
> }
>
> let areSameLength = #keypath(Array<Int>,
> .count).equals(#keypath(Array<String>, .count))
> // BinaryPredicate<Array<Int>, Array<String>>
> if areSameLength.evaluate([1,2,3], [“a”, “b”, “c”]) {
> print(“same lengths”)
> }
Apologies, been working with lots of generic closures today and the ‘Result’
just came out instinctively. Of course the Result of a predicate is a Boolean…
Still, it’s useful to think about what some more advanced use-cases of keypaths
might look like with this proposal. As far as syntax is concerned, operators
may ultimately be the best way to make long predicate combinations cleaner.
extension UnaryPredicate {
static func &&<P>(left: UnaryPredicate<P>, right: UnaryPredicate<P>) ->
UnaryPredicate<P> {
return UnaryPredicate { self($0) && other($0) }
}
}
let isHealthyPuppy = #keypath(Pet, .type).equals(.dog) && #keypath(Pet,
.age).isLessThan(12) && #keypath(Pet, .health).equals(.good)
vs
let isHealthyPuppy = #keypath(Pet, .type).equals(.dog).and(#keypath(Pet,
.age).isLessThan(12)).and(#keypath(Pet, .health).equals(.good))
- Karl_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
