Sent from my iPad
> On Jun 4, 2017, at 12:16 PM, Chris Lattner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>>> On Jun 1, 2017, at 3:06 PM, John McCall via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>>
>>>
>>> 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> 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.
I've been quietly following the thread. This approach makes sense to me.
>
> -Chris
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
