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

[Haravikk]

> On 6 Apr 2017, at 06:56, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
> On 6 Apr 2017, at 04:21, Ricardo Parada via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> 
>>> On Apr 5, 2017, at 9:41 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> It's worth noting that, if you write `\Person.name.valueType`, this syntax is ambiguous—it could mean "make a key path for the `valueType` property on `name` property of `Person`", or it could mean "make a key path for the `name` property of `Person`, then access the key path's `valueType` property". We can solve this by always interpreting it as the former and requiring parentheses for the latter—that is, `(\Person.name).valueType`—but I thought it was worth calling out explicitly.
>> 
>> Good point. 
>> 
>>  I'm thinking about the hypothetical code examples from previous emails:
>> 
>> 
>>    let isPuppyQualifier = \Pet.type == .dog && \Pet.age < 12
>>    let familyQualifier = (\Family.pets).contains(where: isPuppyQualifier)
>>    let familiesWithPuppies = Family.fetch(editingContext, familyQualifier)
> 
> Couldn't the compiler see there exists no contains property on pets and allow us to avoid the parentheses?

Probably, but IMO it actually looks better, and is clearer, with the brackets anyway, so encouraging their use could be a good thing perhaps?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170406/572d0e54/attachment.html>