[swift-evolution] Revisiting SE-0110

[Mark Lacey]

> On Jun 6, 2017, at 1:59 PM, Stephen Celis <stephen.celis at gmail.com> wrote:
> 
>> On Jun 6, 2017, at 1:43 PM, Mark Lacey via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Unless I am missing something this is an example of tuple destructuring. I’m looking for examples of other issues.
> 
> The destructuring issue is the most pervasive, but as mentioned it also breaks point-free style:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170529/036911.html
> 
> Again, less common for most but heavily used by us and folks that use functional patterns and libs like RxSwift, ReactiveCocoa, etc., where a lot of streams/signals of values are composed into new structures.

Thanks for reminding me. It’s good to call out this case specifically. The underlying reason that this is disallowed for Swift 4 is the same as the underlying reason that a closure immediately passed as an argument (with with mismatching function type) is disallowed for Swift 4 (i.e. the “tuple destructuring” case). It might be possible to relax restrictions to allow one of these without allowing the other.

Having said that, I find it surprising that your tupleUp function works as it is implicitly converting the function type in a way that I would expect SE-0110 to disallow. My expectation is that it would need to be written like this:

func tupleUp<A, B, C>(_ f: @escaping (A, B) -> C) -> ((A, B)) -> C {
  return { f($0.0, $0.1) }
}

Mark