> On May 20, 2016, at 10:25, John McCall <rjmcc...@apple.com> wrote: > >> On May 19, 2016, at 4:13 PM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> On May 14, 2016, at 22:16, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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? > > The bug we're talking about is that closures have to have a reference to $n > when there are n+1 parameters.
Oh, I completely forgot that it’s only $n you have to reference, not $n-1 or anything else. So I guess it’s not quite serving the purpose I thought it was. Jordan
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
