[swift-evolution] Smart KeyPaths

[Haravikk]

> On 31 Mar 2017, at 12:33, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> On Mar 31, 2017, at 3:07 AM, Haravikk via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 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.

Is it always in the form of $R<n>? If it can't include periods then it doesn't seem like it would present a collision (just as overlap with $0, $1 etc. in closures does not).

>> 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.

Ack, no idea how I forgot about attributes considering I use them all the time. Hmm.

>> 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.

Perhaps, but how many other features might be making a bid for it? There's always the possibility of using a more "specialised" bracket for paths instead, like #{Person.friend.lastName}
Leaving regular parenthesis up for grabs for something else.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170331/d9f65c88/attachment.html>