Some small keypath extensions: identity and tuple components

Evolution Pitches
21

Since identity key paths would require some runtime support before ABI stability, I went ahead and implemented that backend support (without a finalized surface syntax) here:

15 Likes
22

Here's a formal proposal for the identity key path: Proposal for identity key paths by jckarter · Pull Request #895 · apple/swift-evolution · GitHub

4 Likes
23

Sorry to resurrect this old topic, but did we ever discuss or implement decomposition? I happen to need it now.

24

@Alejandro might've been working on something in that space since he's been working on reflection more generally. If you don't need the KeyPath-ness specifically, but just the syntax, maybe a macro could decompose a key path literal for you to interpret as you need.

25

Keypath decomposition shouldn't be too difficult with keypath's current representation. Optional chaining would be kind of awkward to represent fully without CaseKeyPath and/or OptionalWritableKeyPath, but the rest of the cases should be supported with the existing keypath types. Is there something more complex to decomposition that you needed besides maybe a simple KeyPath.decomposed() -> [AnyKeyPath]? @dabrahams

3 Likes
26

Would it allow answering the question of checking if the two keypaths are related?

27

If you decompose both keypaths and do equality checking on each of the "component" key paths to find the first non-equal one yeah. Can see if they are "related" and exactly which component diverges the two.

2 Likes
28

Great, looking forward to trying it. Do you have an idea when could we get it?

29

Thanks; It's not about the literal; I want the KeyPath operation that undoes the appending() operation that's already there (I only happen to care about the prefix and not the tail element).

1 Like
30

What I'd probably want is something like KeyPath<Root, Leaf>.decomposed() -> (prefix: PartialKeyPath<Root>, last: AnyKeyPath), given the types we have now.

Notionally, KeyPath<Root, Leaf>.decomposed() -> (prefix: KeyPathFrom<Root>, last: KeyPathTo<Leaf>), where prefix just drops the last step.

1 Like
31

All that said, I could probably work with the signature you suggested, @Alejandro