> On 30 Mar 2017, at 17:18, Joe Groff <[email protected]> wrote:
>
>
>> On Mar 30, 2017, at 6:54 AM, Haravikk via swift-evolution
>> <[email protected]> wrote:
>>
>>
>>> On 30 Mar 2017, at 14:12, Matthew Johnson via swift-evolution
>>> <[email protected]> wrote:
>>>> On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution
>>>> <[email protected]> wrote:
>>>> I'm not a fan of the new syntax for creating key paths. To me, it feels
>>>> like they've been demoted to second class citizens of the language simply
>>>> because of how more verbose it now is. The new syntax is also too
>>>> confusingly similar to string key paths: I had to look closely at the code
>>>> to see the difference. Is there no symbol we can use to make it ambiguous?
>>>> Ideas:
>>>>
>>>> Person::friend.lastName
>>>> Person/friend.lastName
>>>> Person#friend.lastName
>>>>
>>>> I'm a fan of the first one as it has similarities to names pacing in C++.
>>>
>>> I'm a big fan of the last one. I argued for it earlier as the best syntax
>>> to use if we deviated from the initial proposal. I like it for several
>>> reasons:
>>>
>>> - # suggests compiler magic is at work which is the case here.
>>> - #friend.lastName works nicely as a shorthand in contexts expecting a key
>>> path with a fixed Root
>>> - # would work for unbound methods solving the no arguments case. IMO all
>>> unbound members should be accessed using the same syntax.
>>> - # enables the possibility of mixing property access and method calls in
>>> the path as a future enhancement
>>>
>>> The arguments supporting this approach are pretty strong to me. I agree
>>> with David that the #keyPath syntax makes it feel more like a second class
>>> citizen, not just because of the verbosity but also because it is directly
>>> borrowed from an Objective-C interop feature. This is a very powerful
>>> feature that deserves to be a first class syntactic citizen every bit as
>>> much as unbound methods do.
>>
>> Personally I'd prefer the use of a leading dollar sign for this, for example:
>>
>> $Person.friend.lastName
>>
>> I find a symbol midway through the path a bit strange, plus the leading
>> dollar sign already implies compiler magic in the same way as anonymous
>> parameters in closures. In fact you can think of anonymous parameters as a
>> kind of special key-path of sorts, and there should be no ambiguity.
>>
>> I prefer this to the hash symbol for compiler directives, since those feel
>> more like things that are done once during compilation, rather than
>> something you actually use at run-time, so I like the distinction of another
>> symbol for that.
>
> $ is reserved for the debugger. We don't really have many free symbols to
> burn, and it would be unwise to burn one on a new feature before having
> evidence that it deserves it.
Is it actually in-use or just reserved? Not sure I've ever needed it in the
debugger.
What about @? It has a certain appropriateness in how it reads for a path like:
@Person.friend.lastName
Another alternative might be something like an unnamed compiler directive, for
example: #(Person.friend.lastName)
If you consider the statement to mean "expand this".
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
