Files
swift-mirror/test/expr/closure/basic.swift
Chris Lattner a20fa87712 Fix a bug that I noticed when doing the parameter rework, where we'd accidentally
accept closure arguments with API names (but only in a parenthesized parameter list).
While it could theoretically be interesting to support API names on closures, this
is never something we intended to support, and a lot of implementation work would be
necessary to make them correct.  Just correctly reject them even if parenthesized.
2016-01-09 21:20:13 -08:00

44 lines
1.1 KiB
Swift

// RUN: %target-parse-verify-swift
func takeIntToInt(f: (Int) -> Int) { }
func takeIntIntToInt(f: (Int, Int) -> Int) { }
// Simple closures
func simple() {
takeIntToInt({(x: Int) -> Int in
return x + 1
})
takeIntIntToInt({(x: Int, y: Int) -> Int in
return x + y
})
}
// Closures with variadic argument lists
func variadic() {
var f = {(start: Int, rest: Int...) -> Int in
var result = start
for x in rest {
result += x
}
return result
}
f(1)
f(1, 2)
f(1, 3)
let D = { (Ss ...) in 1 } // expected-error{{'...' cannot be applied to a subpattern which is not explicitly typed}}, expected-error{{unable to infer closure type in the current context}}
}
// Closures with attributes in the parameter list.
func attrs() {
_ = {(inout z: Int) -> Int in z }
}
// Closures with argument and parameter names.
func argAndParamNames() -> Int {
let _: (x: Int, y: Int) -> Int = { (a x, b y) in x + y } // expected-error 2 {{closure cannot have keyword arguments}}
let f1: (x: Int, y: Int) -> Int = { (x, y) in x + y }
f1(x: 1, y: 2)
return f1(x: 1, y: 2)
}