On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution < swift-evolution@swift.org> wrote:
> > I understand that there are developers who dislike SE-0110's impact on > certain kinds of functional programming, but that is a very broad complaint > that is unlikely to reach consensus or acceptance, especially for Swift 4. The impact of SE-0110 as currently implemented in Swift 4 leads to following migration choice wherever you have a closure that takes tuple argument: * concise but obfuscate code ($0.1, ...) * readable but verbose code (requiring a ton of boilerplate: intermediate argument, expand signature to include return type, desctructure tuple on new line using let, add return clause) Maybe I misunderstood you, but I don't think this is marginal issue affecting only some "developers that dislike the impact on certain kinds of functional programming". This is a HUGE regression to the usability of all closure with tuple arguments. I'd wager that is the prevailing consensual opinion of anyone who has experienced this issue in practice. I would go as far as to claim that current implementation of SE-0110 does not conform to the Swift 4's goal of backwards source compatibility. > In contrast, I think we may be able to gain consensus on a more targeted > proposal that just re-admits tuple destructuring in closures, assuming we > can find an acceptable implementation. >From what I understand our options are quite limited because of tight constraints of Swift 4's emphasis on backwards source-compatibility and impending release deadline: * effectively revert SE-0110 by always using the codepath for Swift 3 compatibility mode * implement full tuple destructuring (unexplored issues with syntax and backwards compatibility) (Note that Swift 3 didn't support full tuple destructuring - SR-4738 <https://bugs.swift.org/browse/SR-4738>) --Pavol
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution