[swift-evolution] [Pitch] KeyPath based map, flatMap, filter

[Dave Abrahams]

on Wed Jul 05 2017, Brent Royal-Gordon <brent-AT-architechies.com> wrote:

>> On Jul 5, 2017, at 2:23 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I am not convinced this syntactic sugar is worth complicating the
>> language or library for,
>
> For what it's worth, I think it is *totally* worth complicating the
> language or library. The manual alternative involves a ton of
> obfuscating code and punctuation:
>
> 	person.map { $0[keyPath: myKeyPath] }	// Don't tell me this isn't horrible.

It isn't horrible to me, except for the name “myKeyPath” ;-).

I'm not sure what you're objecting to about this.  Is it the very
appearance of curly braces?  There is not a world in which all of your
map's can be written by passing something that already has a concise
name, so closures will arise.  I personally find a closure much easier
to process mentally than some of the instances of

          person.map(someName.or.other)

I've seen.  They're more compact, but less general, and for me at least,
it takes an extra half-second or so to understand maps in the latter
form.  I tend to be cautious about writing higher-order functional code
without writing out closures for this reason.

>> 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.
>
> However, I think making `KeyPath<Foo, Bar>` a subtype of `(Foo) ->
> Bar` is a great way of handling this whole problem in one fell
> swoop—as long as it doesn't get delayed three or four versions while
> we clean up the type system.

I think you may underestimate the cost of releasing something you don't
really want in the long run.  Features are hard to take back (and
increasingly so as we converge on stability).  This one could easily
become much bigger than it is, because we'd have no reason not to do the
same thing for every other closure argument everywhere.  Personally, I
can't imagine that this bit of (very nice, but still) syntactic sugar
would take priority over the long-term health of the language.

-- 
-Dave