> On May 14, 2016, at 22:16, Chris Lattner via swift-evolution > <[email protected]> wrote: > > On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution > <[email protected]> wrote: >>> This encourages the use of empty closures over optional closures, which I >>> think is open for debate. In general I try to avoid optionals when they can >>> be precisely replaced with a non-optional value. Furthermore, most Cocoa >>> completion handlers are not optional. >>> >>> The alternative is to not do this, but encourage that any closure that >>> could reasonably be empty should in fact be optional. I would then want >>> Cocoa functions with void-returning closures to be imported as optionals to >>> avoid "{ _ in }". >> >> +1. In general, I think we should allow implicit arguments, without >> requiring the closure to use all the implicit $n variables like we do today. >> These should all be valid: >> >> let _: () -> () = {} >> let _: (Int) -> () = {} >> let _: (Int, Int) -> Int = { 5 } >> let _: (Int, Int) -> Int = { $0 } >> let _: (Int, Int) -> Int = { $1 } > > I agree, but I consider this to be an obvious bug in the compiler. I don’t > think it requires a proposal.
Sorry to find this thread late. I don’t think this is just a bug; it’s also a way to check that a parameter isn’t getting forgotten. For a single-expression closure that’s probably overkill, but maybe we’d keep the restriction for multi-statement closures? Jordan
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
