[swift-evolution] [Pitch] KeyPath based map, flatMap, filter
Xiaodi Wu
xiaodi.wu at gmail.com
Wed Jul 5 18:08:00 CDT 2017
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 <
swift-evolution at swift.org> wrote:
>
> on Wed Jul 05 2017, Benjamin Herzog <swift-evolution at swift.org> 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 }
> >
> > Link to pull request: 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170705/645f55fb/attachment.html>
More information about the swift-evolution
mailing list