> On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic <p...@pali.sk> wrote: > > On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto: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".
You're misunderstanding me. I have explicitly said, several times, that I agree that the impact on tuple destructuring in closures is a serious regression. There have *also* been objections to losing argument-splat behavior, and while that does negatively affect some functional styles, I think it would be a mistake to try to address that now. John. > > 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
