I’d like to hear thoughts on extending trailing closure syntax to avoid long inline closures. A significant benefit to adopting this sugar would be to clarify indentation style for long inline closures. I apologize if this has been brought up before, but I couldn’t find anything searching the list.
There is a lot of discussion about hacking around the issues with inline closures. Here are a few examples: https://www.natashatherobot.com/swift-trailing-closure-syntax/ https://owensd.io/2015/02/20/handling-multiple-closure-parameters/ https://bugs.swift.org/browse/SR-1199 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020470.html I think a syntax similar to property accessors to allow multiple trailing closures could make these scenarios feel swifty. Property accessors already have a "get" specialization that is similar to the current trailing closures syntax, so in theory this could be a backwards compatible extension. func foobar(a: Int, b: Int, completionBlock: ((Int, Int) -> Void), failureBlock: ((Int, Int) -> Void) { // ... } // Current syntax: foobar(a: 1, b: 2, completionBlock: { x, y in // ... }, failureBlock: { i, j in // ... }) // A sugar similar to property accessors for multiple trailing closures: foobar(a: 1, b: 2) { completionBlock { x, y in // ... } failureBlock { i, j in // ... } } Best, Eric
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
