If we had gone with the operator overloading approach, a predicate's construction would look quite similar, something along the lines of:
let predicate = Predicate<Message> {
$0.content.count < limit && $0.sender.firstName == "Jeremy"
}
However, in order to support just the operations present in this predicate we would have to add 9 new overloads combined to the <, &&, and == operators (each new allowed operator would have 3 overloads: one for a PredicateExpression on both sides, one for a PredicateExpression on the LHS with a constant on the RHS, and one for a constant on the LHS with a PredicateExpression on the RHS). These operators would be defined in Foundation and would return a built PredicateExpression rather than the result of the operator (like a Bool). In addition to the inability to produce meaningful compilation error messages and represent other operators such as conditionals and casting, it is unfortunately a known issue in Swift that adding new operator overloads can drastically increase the amount of time for which type checking an expression can take. We felt that adding a very large number of new operator overloads to an almost universally imported framework would lead to regressions in build times that were untenable. If you're curious about the build-time issues here, you can search around for other forum posts and GitHub issues about the compiler being unable to type check an expression in a reasonable time (such as this post for example), or @hborla can provide some more context on that.