Thanks for the feedback! I also like the idea where this is pivoting and would like to think deeper about the topic and possible solutions. I will change the proposal and polish it. I would still like to use this thread to get more input if there is more.
______________________ Benjamin Herzog > On 6. Jul 2017, at 01:15, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > My initial reaction when this idea was floated was positive, but after Dave > and others' astute observations, I have come to the same opinion as him. > Namely, it seems hard to justify adding an overload that's purely syntactic > sugar, multiplying the number of ways to express the same thing, for a result > where the increase in readability is debatable. > > Agree also that _if_ this is worthwhile, then keypaths as a subtype of the > corresponding function type would be the best way to go. > > > On Wed, Jul 5, 2017 at 4:23 PM, Dave Abrahams via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > on Wed Jul 05 2017, Benjamin Herzog <[email protected] > <mailto:[email protected]>> wrote: > > > Hey guys, > > > > I would like to pitch a small convenient change to the Swift stdlib. > > With KeyPaths added in SE-0161 I would like to add some convenience > > calls to map, flatMap and filter in Sequences. To extract properties of > > an array of objects we currently use trailing closure syntax together > > with the shorthand $0 for the first closure argument. This is still kind > > of verbose and also hard to read in some situations.I think it is much > > better to understand what is > > going on when using the > > type safe KeyPaths for that. I already implemented a working solution > > and would like to pitch the idea here to get some feedback before > > opening the swift evolution proposal.I propose using > > > > persons.flatMap(keyPath: \.name) > > > > over > > > > persons.flatMap { $0.name <http://0.name/> } > > > > Link to pull request: https://github.com/apple/swift/pull/10760 > > <https://github.com/apple/swift/pull/10760> > > Repeating my earlier response to this idea: > > I am not convinced this syntactic sugar is worth complicating the > language or library for, but if it is, IMO the right thing is to make a > keypath be-a subtype of the appropriate function type, rather than to > start down the path of creating a keypath overload for every method that > takes a closure argument. > > -- > -Dave > > _______________________________________________ > 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] > https://lists.swift.org/mailman/listinfo/swift-evolution
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
