> On 31 Mar 2017, at 12:33, Brent Royal-Gordon <[email protected]> wrote:
>
>> On Mar 31, 2017, at 3:07 AM, Haravikk via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
