>> func notOverloaded1(_ closure: (Int, Int) -> Int) -> String { return >> "notOverloaded1" } >> func notOverloaded2(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String >> { return "notOverloaded3" } >> >> func overloaded(_ closure: (Int, Int) -> Int) -> String { return >> "overloaded 1" } >> func overloaded(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { >> return "overloaded 2" } >> >> // not overloaded => not ambiguous >> notOverloaded1 { x, y in x + y } >> notOverloaded1 { (x, y) in x + y } >> notOverloaded1 { _ in 1 } >> notOverloaded2 { x, y in x + y } >> notOverloaded2 { (x, y) in x + y } >> notOverloaded2 { _ in 1 } >> >> // overloaded => resolve ambiguity on closure argument, when possible >> overloaded { x, y in x + y } // "overloaded 1" >> overloaded { (x, y) in x + y } // "overloaded 1" >> overloaded { t in t.lhs + t.rhs } // "overloaded 2" >> overloaded { (t) in t.lhs + t.rhs } // "overloaded 2” > > This is exactly what happens today as a result of SE-0110 since the first two > calls take two arguments, and the next two take a single argument.
No, as a playground quickly reveals: func notOverloaded1(_ closure: (Int, Int) -> Int) -> String { return "notOverloaded1" } func notOverloaded2(_ closure: ((lhs: Int, rhs: Int)) -> Int) -> String { return "notOverloaded3" } // not overloaded => not ambiguous notOverloaded1 { x, y in x + y } notOverloaded1 { (x, y) in x + y } notOverloaded1 { _ in 1 } // Swift 4 error notOverloaded2 { x, y in x + y } // Swift 4 error notOverloaded2 { (x, y) in x + y } // Swift 4 error notOverloaded2 { _ in 1 } Those errors are the famous regressions we want to fix. >> overloaded { _ in 1 } // error: ambiguous use of >> ‘overloaded' > > With SE-0110 in its current form, this calls the tuple version since there is > a single closure parameter listed. It would be nicer if. { _ in ... } would always mean "I don't care". With an ambiguity in the sample code we're looking at, and a compiler error. The { (_, _) in ... } form is arguably cluttered, and it would be nicer it is was required only for disambiguition. >> overloaded { (_) in 1 } // "overloaded 1” > > With SE-0110 in its current form, this calls the tuple version since there is > a single closure parameter listed. I don’t understand why you would suggest > this should call the two-argument version since that’s inconsistent with the > other closures above that have a single argument. > >> overloaded { (_, _) in 1 } // "overloaded 2” > > With SE-0110 in its current form, this calls the two-argument version since > there are two listed arguments. I was wrong, sorry. I meant what you replied. Gwendal
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution