> On Apr 5, 2017, at 7:32 PM, David Smith via swift-evolution > <[email protected]> wrote: > > The rationale for using the same syntax is that a KeyPath is an unapplied > property/subscript access. Even the multi-segment part of it isn't > necessarily dissimilar: I don't think it would be unreasonable to imagine > that \Foo.someMethod.someOtherMethod could work*, that'd just be function > composition after all. > > KeyPath : Properties/Subscripts :: Functions with a self argument : Methods > > David > > *not proposing this, haven't thought carefully about whether there are edge > cases I'm missing here, but I think the analogy holds
I alluded to this kind of thing in the earlier threads. It would be very cool to see this explored in the future. I really like the latest draft and am eagerly anticipating Smart KeyPaths being implemented. Thank you for listening to feedback from the community! One possible future direction I have been wondering about is whether it might be interesting to expose an anonymous type for each distinct key path which would have static members for getting (and setting if mutable) the value. The types would inherit from the most specific matching key path type included in this proposal. This would allow us pass key paths statically using the type system and therefore not requiring any runtime overhead. I have experimented with this approach in some of my own code and it looks like it would be a very promising approach aside from the boilerplate required to write these types manually. I have abandoned this approach for now because of the boilerplate and because the syntactic sugar of the key path shorthand in this proposal is too attractive to pass up. I would love to explore it again in the future if key paths were to support this approach. Matthew > >> On Apr 5, 2017, at 5:16 PM, Patrick Smith via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> I too find the backslash odd, as it’s usually of course used to escape >> something. >> >> What about three periods? >> >> let firstFriendsNameKeyPath = Person...friends[0].name >> print(luke[keyPath: ...friends[0].name]) >> >> >> I also find wanting to use the same syntax for unapplied methods strange, as >> they would product two totally different things: one a key path value, the >> other a function. >> >> Patrick >> On Thu, 6 Apr 2017 at 10:00 am, Douglas Gregor via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >>> On Apr 5, 2017, at 4:55 PM, Colin Barrett <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Is the choice of backslash up for review? I think another operator, >> >> We talked through basically everything on the keyboard, and there really >> aren’t other options that don’t stomp on existing behavior. >> >>> perhaps backtick (`), would work better. >> >> Backtick (`) is already taken for escaping identifiers, e.g., >> >> var `func` = { /* some code */ } >> >> - Doug >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
