-1 A -1 from me may be surprising. I'm excited about key path composition and generic solutions, e.g. this experiment with lenses: https://twitter.com/stephencelis/status/863916921577758721
But I'd prefer a reusable solution for converting key paths into functions. Heaven help me for this Rubyism, but a prefix "&" operator (or, maybe better yet, some implicit mechanism) could convert a key-path to a function that passes a root value to a key path... people.map(&\.firstName) This way any function that takes a transformation from "whole" to "part" could take a key path. Requiring an overload per instance is less flexible. Stephen > On Jun 7, 2017, at 10:58 PM, Tony Allevato via swift-evolution > <[email protected]> wrote: > > +1, I really like this. It would also align nicely with the method type > flattening in SE-0042 (once it gets implemented), because passing keypaths > (i.e., unbound property references) and unbound parameterless method > references to map/flatMap would look nearly the same: > > ``` > struct Person { > let firstName: String > let lastName: String > func fullName() -> String { return "\(firstName) \(lastName)" } > } > > let people: [Person] > let firstNames = people.map(\.firstName) > let fullNames = people.map(Person.fullName) // because after SE-0042, this > will be (Person) -> String, not (Person) -> () -> String > ``` > > Especially if there's a move in the future to also use \. to denote unbound > methods references, which was discussed during the keypath reviews. (Even > with that, I believe it would be more work though to get rid of the explicit > type name in the function case.) > > > On Wed, Jun 7, 2017 at 6:11 PM Xiaodi Wu via swift-evolution > <[email protected]> wrote: > +1. Would think that all variants should exist on Optional too unless it > would be harmful. > On Wed, Jun 7, 2017 at 20:13 Michael J LeHew Jr via swift-evolution > <[email protected]> wrote: > This is a great idea, and ought to be easy enough to bring forward! +1 from > me! > > -Michael > > > On Jun 7, 2017, at 11:18 AM, Matt Diephouse via swift-evolution > > <[email protected]> wrote: > > > > 💯 > > > >> On Jun 7, 2017, at 10:35 AM, Adam Sharp via swift-evolution > >> <[email protected]> wrote: > >> > >> The new smart key path feature is really lovely, and feels like a great > >> addition to Swift. > >> > >> It seems like it might be straightforward to add overloads of `map` and > >> `flatMap` to the standard library to make use of the new functionality: > >> > >> let managers = flatOrganisation.managers > >> let allEmployees = Set(managers.flatMap(\.directReports)) > >> let employeeNames = Set(allEmployees.map(\.name)) > >> > >> This feels like a really natural way of working with key paths in a > >> functional style. It makes a lot of sense for collections, and possibly > >> for Optional too (although as far as I can see optional chaining is more > >> or less equivalent, and with more compact syntax). > >> > >> I’m hoping that this might be low-hanging fruit that could be considered > >> for the Swift 4 release. I’d be happy to have a go at writing a proposal > >> if there’s interest! > >> > >> –Adam > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > 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 > _______________________________________________ > 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
