Thanks a lot @DTS Engineer Ziqiao Chen for that clear explanation.
The last sentence you mention is key and very valid:
I'd go further to make it a rule: Inside the closure of #Predicate, use if let only for unwrapping optional persistent properties of the model; move external parameter branching in Swift outside of the macro.
I am no expert but given below are my thoughts:
Predicate can be used in SwiftData and outside SwiftData for filtering.
There is a problem with this approach there are some restrictions with using it in SwiftData with which you pointed out and many more that aren't allowed.
I feel it is better to provide another a predicate type (sample name: DataPredicate) specifically for SwiftData.
This would be better because DataPredicate can have more restrictions at compile time by not allowing optional values and other rules.
The current approach often catches most programmers off guard primarily because on the surface it offers some compile time checks and lacks some which are caught at runtime.
Separate type would allow Apple to add more safety to DataPredicate to allow only what can be translated into SQL / valid commands under the hood at the same time keeping Predicate as it is.
On a side note:
Please provide feature parity with NSPredicate, currently Predicate doesn't support regex
is there a way / workaround to use regex in Swift Data predicate?