Smart KeyPaths

Date: Fri, 31 Mar 2017 04:33:43 -0700
From: Brent Royal-Gordon <>
To: Haravikk <>
Cc: Haravikk via swift-evolution <>
Subject: Re: [swift-evolution] Smart KeyPaths
Message-ID: <>
Content-Type: text/plain; charset="utf-8"

Is it actually in-use or just reserved? Not sure I've ever needed it in the debugger.

Pop into the REPL for a minute:

  $ swift
  Welcome to Apple Swift version 3.1 (swiftlang-802.0.41 clang-802.0.36). Type :help for assistance.
    1> "hello"
  $R0: String = "hello"
    2> $R0
  $R1: String = "hello"

You may not have ever noticed it was there, but it was.

What about @? It has a certain appropriateness in how it reads for a path like: @Person.friend.lastName

We're already using @ for attributes; I don't think we want to overload its meaning.

Another alternative might be something like an unnamed compiler directive, for example: #(Person.friend.lastName)
If you consider the statement to mean "expand this".

The unnamed compiler directive seems like *really* valuable real estate, arguably much more so than unresolved-member-on-KeyPath-type is. I think it'd be foolish to assign it to anything before we have a macro system designed.

I agree that #() is too valuable to burn at this point.

So… Crazy Thought: Is KeyPath enough of a term-of-art beyond ObjC that we want to carry it’s semantics directly into Swift even when it conflicts with established ObjC inter-op? In other words, if we didn’t already know ObjC & KVO/KVC, does “KeyPath” mean what we mean by it in Swift?

If the issue is the conflict with the current semantics of keypath(), what about something like:

   let fooProp: Property<Foo, String> = #property(bar.bast)

And in the inferred/ambiguous case:

    let fooProp = #property(bar.bast, of: Foo)

It perhaps moves too far from the KeyPath nomenclature, but it reads rather nicely (IMHO).



On Mar 31, 2017, at 3:07 AM, Haravikk via swift-evolution <> wrote: