Error depending on position of closure's inout argument

[benrimmington]

Is this a compiler bug?

Yes, see SR-1528.

Perhaps it has been fixed in Swift 5?

No, not in the latest Swift 5.0 snapshot.

Removing "_ in" from empty closures

+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 } -Joe

···

On May 13, 2016, at 9:13 AM, Rob Napier via swift-evolution <swift-evolution@swift.org> wrote: Currently if a closure takes a value, it requires "_ in"…

Removing "_ in" from empty closures

I agree, but I consider this to be an obvious bug in the compiler. I don’t think it requires a proposal. Unfortunately it is non-trivial to fix… -Chris

···

On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <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 hand…

Removing "_ in" from empty closures

Yeah, this is just a bug which several people have made various efforts over the last three years to fix. It's not easy. John.

···

On May 14, 2016, at 10:16 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote: On May 13, 2016, at 9:16 AM, Joe Groff via swift-evolution <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 preci…