2017-06-05 2:16 GMT+09:00 Chris Lattner via swift-evolution < [email protected]>:
> > On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution < > [email protected]> wrote: > > > On Jun 1, 2017, at 2:39 PM, Pavol Vaskovic <[email protected]> wrote: > > On Thu, Jun 1, 2017 at 8:52 PM, John McCall via swift-evolution < > [email protected]> 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. > > > I agree with both points: we need to fix the type checker > semantics+performance regression, but I also sympathize with the beauty > regression for closures. Here are some the examples Gwendal Roué cited > up-thread (just to make the discussion concrete): > > Example 1 > - return columns.index { (column, _) in column.lowercased() == > lowercaseName } > + return columns.index { $0.0.lowercased() == lowercaseName } > > Example 2 : > - .map { (mappedColumn, baseColumn) -> (Int, String) in > + .map { (pair) -> (Int, String) in > + let mappedColumn = pair.key > + let baseColumn = pair.value > > Example 3 : > - .map { (table, columns) in > "\(table)(\(columns.sorted().joined(separator: > ", ")))" } > + .map { "\($0.key)(\($0.value.sorted().joined(separator: > ", ")))" } > > Example 4 : > - dictionary.first { (column, value) in > column.lowercased() == orderedColumn.lowercased() } > + dictionary.first { $0.key.lowercased() == > orderedColumn.lowercased() } > > > > > One way to split the difference here is to eliminate the splatting > behavior, but keep the destructuring (irrefutable pattern matching) > behavior as well. In these cases, just require an extra explicit paren for > the parameter list. This would change the diff's to: > > Example 1 > - return columns.index { (column, _) in column.lowercased() == > lowercaseName } > + return columns.index { ((column, _)) in column.lowercased() == > lowercaseName } > > Example 2 : > - .map { (mappedColumn, baseColumn) -> (Int, String) in > + .map { ((mappedColumn, baseColumn)) -> (Int, String) in > > Example 3 : > - .map { (table, columns) in > "\(table)(\(columns.sorted().joined(separator: > ", ")))" } > + .map { ((table, columns)) in > "\(table)(\(columns.sorted().joined(separator: > ", ")))" } > > Example 4 : > - dictionary.first { (column, value) in > column.lowercased() == orderedColumn.lowercased() } > + dictionary.first { ((column, value)) in > column.lowercased() == orderedColumn.lowercased() } > > > What do you think? Seems like it would solve the type checker problem, > uglify the code a lot less, and make the fixit/migration happily trivial. > > +1. Migration path would be a little less simple if the parameter clause has type annotations: - let fn: Int = { (v: String, k: Int) in + let fn: Int = { ((v, k): (String, Int)) in Also, if we accept patterns for closure parameters, we probably don't want to accept '...' for them. let fn = { ((_, v): (Int, String)...) -> Int in > -Chris > > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
