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

[Robert Bennett]

In general, I like the idea of making ordinary types callable (although curried functions already accomplish this to some extent), but I hesitate to bring this capability to keypaths because, well, they don’t really feel like functions; I think the point of them is that they work like subscripts, not functions. After all, before keypaths were added, there was already an easy to make a function that does what a keypath does (which makes me wonder whether keypaths were necessary in the first place, but that ship has sailed). The only reason to add callable support to keypaths is for use in map, which I don’t think justifies making them callable.

Also, since I brought this up, I’d like to be proved wrong about keypaths – what use do they have that isn’t accomplished by the equivalent closure?

> On Jul 11, 2017, at 2:28 PM, Benjamin Herzog via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I still think using an operator for this conversation would neither increase readability nor transparency. I think my mail on Sunday was lost, so I paste the content here again. It referred to a suggestion to create a possibility for KeyPath to act as a function which would bring other benefits as well:
> 
> In Scala you can implement an apply method which makes it possible to call an object just like a function. Example:
> 
> case class Foo(x: Int) {
>     def apply(y: Int) = x + y
> }
> 
> val foo = Foo(3)
> val bar = foo(4) // 7
> 
> That is similar to what you suggested to have a possibility to convert an object to a closure getting called. And I totally see the point for this! I think using a keyword or special name like apply is not a good idea because it's not obvious what it does and it also makes it possible to just call the method with its name: foo.apply(4).
> 
> However, having a protocol is kinda hard because it's not possible to have a flexible parameter list. Maybe having a method without a name? Swift example:
> 
> class Foo {
>     var x: Int
>     init(x: Int) { self.x = x }
>    
>     func (y: Int) -> Int {
>         return self.x + y
>     }
> }
> 
> let foo = Foo(x: 3)
> let bar = foo(y: 4) // 7
> 
> I actually like that, would be like an anonymous function. It would also be possible to have multiple of those defined for one object (which would have to be unambiguous of course).
> 
> So getting back to KeyPath, it could look like this:
> 
> class KeyPath<Root, Value> {
>     func (_ root: Root) -> Value {
>         return root[keyPath: self]
>     }  
> }
> 
> I see that this would be a much bigger change and would not justify the syntactic sugar for map, flatMap, etc. But it would still be a nice addition to the Swift programming language, especially for KeyPath, transformers etc.
> 
> What do you think?
> 
> ______________________
> 
> Benjamin Herzog
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution