Date: Fri, 31 Mar 2017 04:33:43 -0700
From: Brent Royal-Gordon <brent@architechies.com>
To: Haravikk <swift-evolution@haravikk.me>
Cc: Haravikk via swift-evolution <swift-evolution@swift.org>
Subject: Re: [swift-evolution] Smart KeyPaths
Message-ID: <ADB64B59-D79C-41CC-9465-DC4697CB25BB@architechies.com>
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).
—Karim
···
On Mar 31, 2017, at 3:07 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote: