This is another reaction to SE-0066 <https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md> to which I'm mildly against.
I'd like to propose the following language changes to simplify function types and clarify what a function's name is. What gets removed is already ambiguous. And what is added makes higher-level programming with functions considerably simpler than currently. Furthermore, the proposed change considerably limits what constitutes the overload set of a function, which probably also speeds up the compilation process.
Let's consider the following declarations:
func foo() // #1 Function named 'foo(_)' with type '() -> ()'.
func foo(x: Int) -> Int // #2 Function named 'foo(x:)' with type 'Int -> Int' (not an overload).
func foo(_ x: Int) -> Int // #3 Function named 'foo(_:)' with type 'Int -> Int'
func foo(_ x: (Int, Int)) -> Int // #4 Function named 'foo(_:)' with type '(Int, Int) -> Int' (overload of #3).
func foo(x: Int, y: Int) -> Int // #5 Function named 'foo(x:y:)' with type '(Int, Int) -> Int'.
func foo(x: Int, y: Int) -> Bool // #6 Function named 'foo(x:y:)' with type '(Int, Int) -> Bool' (overload of #5).
let foo: Int // error: invalid redeclaration of 'foo' (previously declared as a function)
let baz: (Int, Int) -> Int // #7 Variable named 'baz' with type '(Int, Int) -> Int'.
class Bar {
func baz() // #8 Method named 'Bar.baz(_)' with type 'Bar -> () -> ()'.
func baz(x y: Int) // #9 Method named 'Bar.baz(x:)' with type 'Bar -> Int -> ()'.
static func baz(x: Int = 0) // #10 Static method named 'Bar.Self.baz(x:)' with type 'Int -> ()'.
}
let f1 = foo // error: not a function reference, did you mean 'foo(_)'?
let f2 = foo as () -> () // error: not a function reference, did you mean 'foo(_)'?
let f3 = foo(_) // #11 Function reference to #1. Has type '() -> ()'.
let f4 = foo(x:) // #12 Function reference to #2. Has type 'Int -> Int'.
let f5 = foo(_:) // error: ambiguous function reference. Could be 'Int -> Int' or '(Int, Int) -> Int'
let f6 = foo(_:) as Int -> Int // #13 Function reference to #3. Has type 'Int -> Int'.
let f7 = foo(_:) as (Int, Int) -> Int // #14 Function reference to #4. Has type '(Int, Int) -> Int'.
let x1: Int = foo(x:y:)(1, 2) // #15 Function application of #5. Picks the right overload by explicit return type.
let x2: Bool = foo(x:y:)((1, 2)) // #16 Function application of #6. Allowing a tuple here causes no ambiguity.
let f9 = baz // #17 Function reference synonymous to #7. Has type '(Int, Int) -> Int'.
let bar = Bar()
let f10 = bar.baz // error: not a function reference, did you mean 'bar.baz(_)' or 'bar.baz(x:)'?
let f11 = bar.baz(_) // #18 Function synonymous to the closure '{ bar.baz() }' with type '() -> ()'.
let f12 = bar.baz(x:) // #19 Function synonymous to the closure '{ bar.baz(x: $0) }' with type 'Int -> ()'.
let f13 = Bar.Self.baz(x:) // #20 Function synonymous to the closure '{ Bar.baz(x: $0) }' with type 'Int -> ()'.
let f14 = Bar.Self.baz(_) // #21 Function synonymous to the closure '{ Bar.baz() }' with type '() -> ()'.
The following list of proposed changes sum up what's new above.
C1: Extend SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md> by adding the underscore-in-parentheses syntax `foo(_)` to refer to the zero-argument function #1.
C2: Extend SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md> by removing the ambiguity between instance and type members. From now on, `Bar.baz(_)`
C3: Extend SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md> by banning the use of base name only to refer to a function, i.e. neither `foo` nor `Bar.baz` can be used to refer to refer to any of #1–#6 or #8–#10.
C4: Extend SE-0021 <https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md> to allow the selective omission of defaulted arguments, e.g. `let f = print(_:separator:)` creates the function variable `f: (Any, String) -> ()` equivalent to `{ print($0, separator: $1) }`.
C5: Clarify the language specification by stating that functions with different labels (e.g. `foo(_:)` vs. `foo(x:)`) are not overloads of each other. Instead, two functions are considered overloads of each other if only if they have matching base names (e.g. `foo`) and matching argument labels (e.g. `(x:y:)`) but differing argument or return types (e.g. #3 and #4, or #5 and #6).
C6: Clarify that by using the base name `foo` for a function, the same scope cannot define a variable with the name `foo`. And, vice versa, in a scope that defines a variable named `foo`, there can be no function `foo(...)` defined at the same scope level.
The implications are:
I1: The use of a function's base name to refer to a function will cease to work. It has, however, been buggy up to this date. Consider the following:
let f = [Int].prefix // '[Int] -> Int -> ArraySlice<Int>'
let g1 = [Int].dropFirst // Inexplicably chooses the '[Int] -> Int -> ArraySlice<Int>' overload!
let g2 = [Int].dropFirst as [Int] -> () -> ArraySlice<Int> // Disambiguate by type.
let h1 = [Int].sorted // Chooses the '[Int] -> () -> [Int]' overload, unlike 'dropFirst' above.
let h2 = [Int].sorted as [Int] -> ((Int, Int) -> Bool) -> [Int] // Disambiguate by type.
With the proposed changes, the above becomes:
let f = [Int].prefix(_:) // '[Int] -> Int -> ArraySlice<Int>'
let g1 = [Int].dropFirst(_:) // '[Int] -> Int -> ArraySlice<Int>'
let g2 = [Int].dropFirst(_) // '[Int] -> () -> ArraySlice<Int>'
let h1 = [Int].sorted(_) // '[Int] -> () -> [Int]'
let h2 = [Int].sorted(isOrderedBefore:) // '[Int] -> ((Int, Int) -> Bool) -> [Int]'
I2: When referring to functions the argument labels disappear in the returned function. That's a good thing because there's no generic way to call functions with arguments, and that's why closures too always come without argument labels. We don't, however, lose any clarity at the point where the function reference is passed as an argument because function references always contain the labels in the new notation. (Also, see the future directions for an idea how argument labels can be restored in the function variable.)
I3: Function argument lists are no longer that special and there's no need to notate single-n-tuple argument lists separately from n-argument functions, i.e. SE-0066 <https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md> is not really needed anymore. The new intuition here is that it's the function's name that defines how a function can be called, not its type.
I4: Because function variables cannot be overloaded, we can without ambiguity allow all of the following "tuple splatting":
let tuple1 = (1, 2)
let tuple2 = (x: 1, y: 2)
let tuple3 = (a: 1, b: 2)
let y1 = foo(tuple1) // Not a "tuple splat", calls #4 as normal.
let y2 = foo(tuple2) // Not a "tuple splat", calls #4 as normal.
let y3 = foo(tuple3) // Not a "tuple splat", calls #4 as normal.
let y4 = foo(_:)(1, 2) // Not a "tuple splat", calls the reference to #4 as normal.
let y5 = foo(_:)((1, 2)) // "Tuple splat", calls #4.
let y6 = foo(_:)(((1, 2))) // "Tuple splat", calls #4. Nothing special here, just an unnecessary pair of parens.
let y7 = foo(_:)(tuple1) // "Tuple splat", calls #4.
let y8 = foo(_:)(tuple2) // "Tuple splat", calls #4. The labelled tuple type is compatible with '(Int, Int)'.
let z1 = foo(x:y:)(tuple1) as Int // "Tuple splat", calls #5 because the return type is explicitly 'Int'.
let z2 = foo(x:y:)(tuple2) as Int // "Tuple splat", calls #5. The labels don't really matter here.
let z3 = foo(x:y:)(tuple3) as Int // "Tuple splat", calls #5. Like above, any tuple labels are compatible in the call.
let z4 = (foo(x:y:) as (Int, Int) -> Bool)(tuple3) // Here's another way to explicitly pick up the overload.
Future directions
F1: In this proposal, I made a difference between function identifier names and variable identifier names. However, it could be well allowed to use function-like names for function variables when clarity is needed. Then calling a block would require the argument labels just like functions:
let block(value:) = {value in ...}
block(value: 1)
func foo(_ isOrderedBefore(lhs:rhs:): (Int, Int) -> Bool) {
let x = isOrderedBefore(lhs: 1, rhs: 2)
}
F2: The following idea probably divides opinions, but because function variables are unambiguous, we could even allow calling them without parentheses like in Haskell. That would open up many doors to currying and building highly composable functional libraries:
let f = {x in ...}
let y = f 1 // calls 'f' with an 'Int'
let z = f (1, 2) // calls 'f' with an '(Int, Int)'
F3: And if that was allowed, maybe it could be possible to define functions with variable-like names and currying too, but now I'm getting too far. I think the proposal is worth considering even if we never go to the direction of Haskell in this way.
— Pyry