> 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

Reply via email to