> On 30 Mar 2017, at 14:12, Matthew Johnson via swift-evolution
> <swift-evolution@swift.org> wrote:
>> On 30 Mar 2017, at 01:13, Michael J LeHew Jr via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution