Currently Swift provides a static curried function for every instance function defined. It pretty often allows to avoid closures and be explicit about functions used. For example:
//flip — flipping an order of arguments for curried functions.
var foo = [[0, 1], [1, 2], [2, 3], [3, 4]].map(flip(Array<Int>.prefix)(1)) //[[0], [1], [2], [3]]
However this behavior is not unified, there is no such behavior available for variables or constants. For example code like following is impossible as Array.first is a variable but not a function:
var foo = [[0, 1], [1, 2], [2, 3], [3, 4]].map(Array<Int>.first) //Does not compile, but should be [0, 1, 2, 3]
I was trying to find what cause to not define static curried functions for variables and constants and was not able to find a good reason. It is especially interesting as currently if you define both variable and instance function with the same name, Swift complains about redeclaration of function, so it it treat variable already as a function, but does not provide an alternative way to call it. Moreover following definitions of variable and static functions a conflicting, as variable definitely has its hidden curried implementation somewhere but invisible for others:
class Foo {
var bar: Int = 0
static func bar(self: Foo) -> Int {} //Definition conflicts with previous value
}
One of assumptions why curried functions for variables are hidden — it will cause ambiguity in code, but I was not able to find examples of ambiguity.
Could someone explain why this behavior is not consistent across functions, variables and constants? Should we change it to be consistent and make visible curried static functions for variables and functions? Especially since it is in a nature of current implementation.
Best,
Nikita Leonov
In brief: This has been deferred until after Swift 3. We want to be able to provide read-write access to read-write properties, but Swift can't do that yet. (And at this point in Swift's release cycle, we're not really accepting new features unless they have very large source compatibility impacts, which this change wouldn't.)
Here's one previous discussion from December: <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html> If you want to look at more discussions on this topic, "lens" is a good keyword, although it'll also pick up some unrelated stuff. <Google;
Hope this helps,
···
On Jul 2, 2016, at 12:14 PM, Nikita Leonov via swift-evolution <swift-evolution@swift.org> wrote:
I was trying to find what cause to not define static curried functions for variables and constants and was not able to find a good reason.
--
Brent Royal-Gordon
Architechies
Great! I was trying to find it in a history, but was not able to do so. Thanks for suggestion regarding lens keyword.
···
On Jul 2, 2016, at 3:10 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
On Jul 2, 2016, at 12:14 PM, Nikita Leonov via swift-evolution <swift-evolution@swift.org> wrote:
I was trying to find what cause to not define static curried functions for variables and constants and was not able to find a good reason.
In brief: This has been deferred until after Swift 3. We want to be able to provide read-write access to read-write properties, but Swift can't do that yet. (And at this point in Swift's release cycle, we're not really accepting new features unless they have very large source compatibility impacts, which this change wouldn't.)
Here's one previous discussion from December: <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html> If you want to look at more discussions on this topic, "lens" is a good keyword, although it'll also pick up some unrelated stuff. <Google;
Hope this helps,
--
Brent Royal-Gordon
Architechies