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

[Tony Allevato]

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.


On Sat, Apr 8, 2017 at 6:12 PM Ricardo Parada via swift-evolution <
swift-evolution at swift.org> wrote:

At one point I was leaning towards a trailing backslash.  Now I prefer
parenthesis.

If parentheses are used should the escape character be outside the
parenthesis or inside?  For example:

let x = (\Person.mother.age).valueType
let y = (\Person.mother.age.valueType)

vs.

let x = \(Person.mother.age).valueType
let y = \(Person.mother.age.valueType)


It is a subtle difference.




On Apr 8, 2017, at 5:47 PM, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:


On 8 Apr 2017, at 22:18, BJ Homer via swift-evolution <
swift-evolution at swift.org> wrote:

I love the idea of a leading and trailing backslash. It makes it much
easier to read, and handles the "but what if I want to access a property of
a KeyPath?" case really well.

For example, these two are clearly distinct:

  let x = \Person.mother.age\.valueType

  let y = \Person.mother.age.valueType\

I'm not sure why an 'age' object would have a 'valueType' property, but
this variant makes it easy to handle. Even in cases where no disambiguation
is required, having the trailing backslash makes it much easier to read as
I'm scanning through code.

-BJ


I think I'd prefer brackets for that case; in your first example that reads
to me like an escape of the period character, rather than "this is the end
of the key path". Brackets would make this consistent with escaping within
strings, like so:

let x = \(Person.mother.age).valueType
let y = \(Person.mother.age.valueType)

Which makes sense to me if you consider the backslash in this case being an
escape from normal type/variable access. Put another way, normally when you
type Person. you're telling Swift "access this type and look for static
methods/properties etc.", whereas when you "escape" it you're telling Swift
to *not* to do that, resulting in a key-path instead.

Maybe it's a stretch, it that makes sense logically to me, plus I think the
use of brackets just looks cleaner than another backslash.
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170409/30f00857/attachment.html>