> On Mar 30, 2017, at 6:54 AM, Haravikk via swift-evolution > <swift-evolution@swift.org> wrote: > > >> 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> 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. -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
