Key path getter promotion

Part of our motivation for the \. syntax was that it could also be used eventually for forming closures, in the spirit of SE-42, which was accepted and never implemented. Instead of introducing a subtype relationship, we could (and should) extend the key path literal syntax to be valid in function type context, which I think covers the most common use case for this conversion of passing a literal property reference as an argument to map and friends.

In the fullness of time, when we get generalized existentials I'd like to see key paths be reskinned to be more "protocol-oriented" as well. You could think of closures and read-only keypaths as both being instances of an abstract Applicable protocol, and mutable/observable/lazy/atomic/other-property-behavior key paths as being refinements of that root protocol.

12 Likes