> On Apr 26, 2016, at 6:58 PM, Daniel Duan <[email protected]> wrote: > > Wouldn't this work in Swift 3 though? > > func testFunc(times: Int, fn: (@noescape (Int)->Void)? = nil) { … }
Yes, that got implemented in Swift 3, with a narrow Optional-specific hack :-) -Chris > > Sent from my iPad > > On Apr 26, 2016, at 11:26 AM, Chris Lattner via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> >>> On Apr 26, 2016, at 12:15 AM, Aleksandar Petrovic via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Hi Swift community, I have a question. >>> >>> This is a valid Swift code: >>> >>> func testFunc(times: Int, fn: ((Int)->Void)? = nil) { >>> guard let f = fn else { return } >>> for i in 1 ..< times { >>> f(i) >>> } >>> } >>> >>> And this is not: >>> >>> func testFunc(times: Int, @noescape fn: ((Int)->Void)? = nil) { >>> guard let f = fn else { return } >>> for i in 1 ..< times { >>> f(i) >>> } >>> } >>> >>> I can't think of any hard reason why the @noescape parameter of the >>> function can't be nullable (and, with default value, be optional), but >>> maybe I'm missing something. Is there any plan to correct this in 3.0? >> >> There are two ways to fix this: a horrible hack that special cases >> optionals, or the more principled solution that treats optional as the >> underlying enum type that it is, and making @noescape propagate through to >> the members of the .some case. >> >> You can probably guess this, but I’d prefer to discuss fixing the full >> generality of the problem, not providing a special case in the compiler for >> this. >> >> -Chris >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
