[swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

[Haravikk]

> On 9 Apr 2017, at 05:12, Tony Allevato <tony.allevato at gmail.com> wrote:
> 
> Agreed—I think the parentheses have to go on the outside for this to work. In this sense, `\Person.mother.age` is an expression that returns a keypath type, with the idea that the parser is greedy and tries to take as many dotted names that follow. The parentheses halt that if needed, but the backslash needs to be bound to the type name for the part inside the parentheses to be interpreted as a keypath.
> 
> `\(Foo.bar)` looks like it would try to evaluate `Foo.bar` first and then compute the "keypath" of that, which doesn't make sense, whereas `(\Foo.bar)` makes it clear that the keypath expression is being separated from whatever might come after it.

I kind of like having it outside the brackets for the consistency with inserting variables etc. within strings; I've learned to think of that as a special type of escape from the "string" context, so it could make sense for key-paths in the same way.

I'm just thinking that since we're using a backlash it feels a lot like we're escaping from normal type access in order to define the key-path instead, and since \() is a form of escape used inside strings to encompass something larger it makes a kind of sense to me.

As Brent says though it shouldn't be a very common case so it doesn't really matter; I'd be fine with either style. I suppose using the backslash inside the brackets may be simpler to parse since it's using the parenthesis as normal?