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

Sean Heber sean at fifthace.com
Thu Apr 6 12:54:10 CDT 2017


If single quotes are out, then I would suggest requiring a parenthesis. I guess I just don’t like that it’s unbounded and I’m sure that’s some kind of personal preference thing, but what isn’t around here? :P

For example:

\(Person.name)

instead of:

\Person.name

I think an argument could be made that the pattern of \(..) in Swift could more or less come to mean, “escape this context” which is sort of how it is in string interpolation - you’re saying “evaluate this part as if it wasn’t embedded inside this string construct." A keypath is similar because it’s like, “one level higher”, so to reference a keypath, you have to “escape” from your current context - which is the source code itself - in order to express it. Sorta?

l8r
Sean


> On Apr 6, 2017, at 11:37 AM, Douglas Gregor <dgregor at apple.com> wrote:
> 
> 
>> On Apr 6, 2017, at 9:31 AM, Sean Heber <sean at fifthace.com> wrote:
>> 
>> 
>>> On Apr 6, 2017, at 11:19 AM, Douglas Gregor <dgregor at apple.com> wrote:
>>> 
>>>> 
>>>> On Apr 6, 2017, at 8:13 AM, Ricardo Parada via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> I agree, there's an analogy between strings and key paths, and in that regards the single quote would make sense.  I would not complain.  
>>> 
>>> The only analogy between strings and key-paths is that the existing Cocoa APIs for key-paths use strings. That’s not an analogy to hang language syntax on, because it’s relevance will fade quickly. 
>> 
>> Why would it fade quickly? Do we expect the concept of keypaths to go away over time? If so, why are we even designing a syntax for keypaths?
> 
> The link between key-paths and strings will go away over time. The *only* reason anyone associates strings with keypaths is because Cocoa’s current key-paths are string-based. This proposal makes any string representation of key-paths an implementation detail that could be used for interoperability with Cocoa’s current system. There is no reason for a type-unsafe string representation to ever be in the user model.
> 
> 
>>> The core team discussed single quotes, and decided that we want to save them for something in the string/character realm.
>> 
>> Are they to be saved for something specific or is this just because a lot of languages use single quotes for character literals? Why is this association any more sacred than an association with Cocoa string keypaths?
> 
> 
> Lots of languages use single quotes for character literals; we may want to bring them back for it.
> 
> 	- Doug
> 



More information about the swift-evolution mailing list