-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Predicate expression with optional key path throws error #476
Comments
I think this behavior that you're seeing is actually unintentional. I'll take a look at the sample project, but this construction should also produce the same fatal error. We likely have a bug in the check that we do for valid key paths that incorrectly lets this one through - thanks for catching that!
As for the optional handling within a keypath, the |
Thanks @jmschonfeld. I'm able to use In my project the key paths are provided in runtime and are partially type erased. This has worked fine when dealing with a generic root type and some simple properties like I created a sample project here: https://github.com/ordo-one/external-reproducers/blob/main/swift/predicate-optional-keypath2/Sources/PredicateKeyPathProviding.swift. The idea is that the user of my API would provide key paths through a protocol, that I can then use to create predicates. Since the key paths can be of varying types, they are type erased with I suppose this is more of a question about key paths than it is about predicates, but any advice would be much appreciated, thanks! |
You're definitely on the right track! Two things from your sample code to take a look at:
With those two changes, your sample code code executes successfully. Does that help? |
Thanks @jmschonfeld. That definitely helps! I've updated the sample project at https://github.com/ordo-one/external-reproducers/blob/main/swift/predicate-optional-keypath2/Sources/PredicateKeyPathProviding.swift so it now compiles. However, my original goal of doing this while agnostic of the types remain. In the updated sample, both |
In your case, this is a scenario where you're trying to unwrap an existential and pass it to a generic function. SE-0352 lifted some restrictions here and current allows doing this for constrained generic parameters, but (I believe) due to source compatibility concerns limits the behavior for non-constrained generic parameters (like your |
Thanks @jmschonfeld—I will try to test this in Swift 6. |
@jmschonfeld I've now tested this with the Swift 6 with I updated my example at https://github.com/ordo-one/external-reproducers/blob/main/swift/predicate-optional-keypath2/Sources/PredicateKeyPathProviding.swift. The code inside |
#if hasFeature(ImplicitOpenExistentials)
let predicate3 = factory.createPredicate2(rootType: Root.self, leafType: failingType)
print("predicate3=\(predicate3)")
#else
func body<Value>(_: Value.Type) -> Value.Type { Value.self }
let predicate3 = factory.createPredicate2(
rootType: Root.self,
leafType: _openExistential(
failingType,
do: body
)
)
print("predicate3=\(predicate3)")
#endif @axelandersson AFAIK |
@vanvoorden Thanks! For future reference I have updated the example at https://github.com/ordo-one/external-reproducers/blob/main/swift/predicate-optional-keypath2/Sources/PredicateKeyPathProviding.swift so it now works both with |
Hello!
I'm using
PredicateExpressions
to build dynamically build predicates. I'm getting an exception when creating aPredicateExpressions.KeyPath
with a keypath like\Dummy.optionalSub?.optionalString
where bothoptionalSub
andoptionalString
are optional values. The exception is:This message is a bit misleading as a predicate with a keypath like
\Dummy.sub.optionalString
, where onlyoptionalString
is optional, can be created without issue.If
optionalSub
is made non-optional, the expression can be created.Am I not creating the expressions correctly, or am I running into an issue here?
I've created a sample project showing the issue here: https://github.com/ordo-one/external-reproducers/tree/main/swift/predicate-optional-keypath.
The text was updated successfully, but these errors were encountered: