KeyPath + String

[BrettLee1 (ATF Booru)]

@bdkjones

TLDR

Swift should add first-class support for string-ifying KeyPath. I realize that you moved heaven and earth to keep KeyPath and String from EVER knowing about each other, but that has forced everyone to jump through lots of hoops.

Consider this case:

Context

I'm trying to turn this Predicate:

let p = #Predicate<Foo> { $0.title == "blah" }

Into this SQL statement's WHERE clause (a thing that Apple explicitly designed for and which they do for SwiftData!): Beginner manifestation tips

SELECT * FROM Foo WHERE title = "blah"

Using the Predicate's expressions property, which hands me a ReferenceWritableKeyPath<Foo, String>:

extension PredicateExpressions.KeyPath: MyPredicateExpression
{
    public func myQuery() -> String
    {
        let kpType = type(of: keyPath)
        let rootType: Any.Type = kpType.rootType
        
        print("string describing keyPath: \(String(describing: keyPath))")
        print("kpType: \(kpType)")
        
        // This is what I WANT:
        return keyPath.propertyName    // A String!
    }
}

The above prints the following, so the name of the property ("title") IS in here somewhere! Printing the description and splitting on the period is fragile though; can't rely on that never changing in the future.

string describing keyPath: \Foo.title
kpType: ReferenceWritableKeyPath<Foo, String>

The Hoops

So you know what people are doing instead? They're writing entire macros to generate THIS so that they can match the KeyPath to the string value they need:

This is crazy. Why force everyone to do this? Why can't KeyPath (at least the specialized types) expose a propertyName string value?

TL;DR: Swift should support turning a KeyPath into a String (e.g., .title → "title"). Devs currently use fragile hacks or macros to extract property names, but native support would simplify this significantly and aligns with SwiftData’s internal use of the feature.

[Helge_Hess1 (Helge Heß)]

@bdkjones

I realize KeyPaths can have multiple path components and that this complicates the picture.

let kp = \Foo.bar.baz.blah

I was just walking over this thing, because at least in EOF you could traverse relationships using just the path.
E.g. say customer.addresses.city = 'Cupertino'. That would create sth like:

SELECT * FROM customer 
  LEFT JOIN address USING (address_id) 
 WHERE address.city = 'Cupertino'

I think that syntax can't work w/ Swift KeyPathes right now. Instead you are supposed to treat the relationship as a collection and do this in the predicate:

#Predicate<Customer> { $0.addresses.contains { $0.name == "Cupertino" } }

Which is much more code, but kinda reasonable from a semantic PoV.

I'm not quite sure yet what happens w/ non-optional to-one relationships though. You would think that $0.address.customer.name = 'x' would/should work. But presumably doesn't/can't?

Edit: Ah, interesting, the Predicate macro seems to split combined key pathes into direct ones. That will make all those things work.