It seems that there is some consensus that the proper way to achieve this is
not to overload map et al. but to provide a way to convert KeyPath to a
function. I agree – not only is this “cheaper”, as overloads of these functions
will not need to be written, but it’s also more general and may prove useful in
a context that we currently don’t foresee.
This being the case, I’ll repeat my proposal that the optimal way to achieve
this is to make $ the conversion “operator” (although it need not, and probably
should not, be a full-fledged operator), so that $keyPath –> { $0[keyPath:
keyPath] }
> On Jul 11, 2017, at 11:13 AM, Elviro Rocca via swift-evolution
> <[email protected]> wrote:
>
> Overloads are ugly. The very existence of an overloaded function usually
> means a lack of available abstractions, or an insufficient abstraction power
> in the language: exhibit A is conditional conformances to protocols.
>
> Overloads are particularly ugly if the overloaded function's input represents
> basically the same thing: a KeyPath<A,B> is really (semantically) just a
> couple of functions, that is, (A) -> B and (inout A,B) -> (), so the (A) -> B
> is already there, and I like the idea of an "extraction" operator that was
> proposed in the thread. It would be really interesting to just use the
> KeyPath<A,B> itself wherever a (A) -> B is required, but this looks like a
> hack given the current state of Swift's type system.
>
> But I like the fundamental idea behind the proposal: KeyPaths give Swift a
> boost in expressive power, and there's probably plenty of use cases that will
> emerge in the future.
>
> Thanks
>
>
> Elviro
>
>> Il giorno 05 lug 2017, alle ore 19:08, Benjamin Herzog via swift-evolution
>> <[email protected]> ha scritto:
>>
>> 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
>>
>> Link to proposal draft:
>> https://github.com/BenchR267/swift-evolution/blob/keypath-based-map/proposals/0181-keypath-based-map-flatmap-filter.md
>>
>> Thanks in advance for your feedback!
>> ______________________
>>
>> Benjamin Herzog
>>
>> _______________________________________________
>> 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
