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

[Robert Bennett]

This is also the case for $0, although I suppose that since $0 is only valid inside a closure, LLDB has some context with which to disambiguate Swift’s $0 from LLDB’s, context it wouldn’t have with $keyPath. That said, there are probably solutions to this, like requiring a backslash before a Swift dollar sign to disambiguate from an LLDB dollar sign. Or something else. Designing the language with constraints imposed by the debugger seems unduly restrictive, though – surely the debugger should be subservient to the language, not the other way around.

> On Jul 11, 2017, at 12:44 PM, BJ Homer <bjhomer at gmail.com> wrote:
> 
> ‘$' as a prefix is reserved for use by the debugger, so it cannot be used as a conversion operator here.
> 
> -BJ
> 
>> On Jul 11, 2017, at 10:12 AM, Robert Bennett via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 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 <swift-evolution at swift.org> 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 <swift-evolution at swift.org> 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
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> 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/20170711/60592d79/attachment.html>