As an addition to our previous Swift Predicates Pitch, we have a followup pitch discussing the archiving behavior for predicates. We hope to provide a safe and secure means of serializing predicates for transmission between processes and devices. Please let us know if you have any questions, comments, or suggestions!
Introduction
Now that we have introduced the base Predicate type along with its related APIs in the Swift Predicates pitch, we'd like to expand upon the serialization capabilities of Predicate. Providing the ability for safe and secure serialization is a critical feature of Predicate since predicates are commonly passed between processes for evaluation in an out-of-process database or even between hosts for communicating with a remote server. In our previous proposal we mentioned that Predicate will be Codable. We'd like to add conformance to Codable and CodableWithConfiguration (as well as expand upon how predicates will be encoded into an archive) in order to support the full range of situations where developers may want to write predicates into an archive.
I've posted the full pitch here as a gist, feel free to check it out the details and please let us know what you think!
Presumably there's a missing in after the closure parameter name?
Also, re. the encoding of it:
Why does 10 not appear anywhere in the encoded form?
What is the magic value "5" that appears repeatedly as the value of the "key" key?
Aesthetically it'd be nice if the standard prefixes were stripped unless really needed, just as they are in Swift code. e.g. just Int instead of Swift.Int unless there actually is a different Int type used in the predicate. Similarly for the predicate expression types.
Yep, I apologize the example should indeed use the in keyword.
It looks like this is also a small typo, I apologize for the confusion. The 2 indicated as the second element of the expression array should be a 10 representing the 10 value from the predicate.
This is an internal key that represents the input variable. The actual value of this number is an implementation detail of predicate and not exposed as the API, but internally it's used as an identifier within the PredicateExpressions.VariableID type.
By default the standard configuration will always use the fully qualified names for these swift types to avoid any potential confusion with a custom type named Int. It is perfectly valid for a client module to define a type like Int (although it would be quite confusing) so we use fully qualified type names here to prevent potential ambiguity. You could choose to craft your own codable configuration that uses unqualified identifiers like "Int" instead of "Swift.Int" so long as your codable configuration doesn't introduce two types with the same identifier.