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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to