> On Mar 29, 2017, at 5:26 PM, Michael J LeHew Jr via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Mar 29, 2017, at 5:12 PM, James Berry <jbe...@rogueorbit.com> wrote: >> >>> Referencing Key Paths >>> >>> Forming a KeyPath borrows from the same syntax added in Swift 3 to confirm >>> the existence of a given key path, only now producing concrete values >>> instead of Strings. Optionals are handled via optional-chaining. Multiply >>> dotted expressions are allowed as well, and work just as if they were >>> composed via the appending methods on KeyPath. >>> >>> There is no change or interaction with the #keyPath() syntax introduced in >>> Swift 3. #keyPath(Person.bestFriend.name) will still produce a String, >>> whereas #keyPath(Person, .bestFriend.name) will produce a KeyPath<Person, >>> String>. >> >> This distinction seems arbitrary and confusing. The user is supposed tor >> remember that the #keyPath(Person.bestFriend.name) form produces a string >> while the #keyPath(Person, .bestFriend.name) form produces a key path >> object? I don’t think we’re advancing here. What would be the effect if just >> the former was valid, and (always/now) produced a keypath object that was >> convertible to string? How bad would the breakage be? > > The syntax subtleties here are unfortunate. > > An idea that we discussed was to be able to tell when a #keyPath wants to be > considered as a string and either implicitly or having some affordance for > doing so. Back then this was harder because we had #keyPaths that could not > be represented as a string (an earlier draft had keyPaths that could compose > with closures; which while powerful, weren't really key paths any more. That > idea was removed from the proposal we shared as they are intrinsically > opposed to being able to serializing/deserialize key paths). > > Given that we don't support those kinds of key paths, nor are we really > considering adding them back thanks to our desire to support serializing key > paths to file in the future, this is a very reasonable idea I think.
One small problem with the Swift 3 key path syntax when generalized to allow arbitrary Swift types at the root, and to also allow inference of the root, is that [...] can be either a subscript or an Array type reference, so it wouldn't be clear whether #keyPath([a].foo) is the path `.foo` rooted on the type `[a]` or the path `[a].foo` rooted in the contextual root type. We could say that you have to use a different syntax for a contextual keypath that begins with a subscript, like `#keyPath(.self[a])` or `#keyPath(.[a])`, perhaps. -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
