[swift-evolution] Revisiting SE-0110

[Tony Parker]

> On May 24, 2017, at 1:01 PM, Pavel Yaskevich <pavel.yaskevich at gmail.com> wrote:
> 
> 
> 
> On Wed, May 24, 2017 at 12:57 PM, Tony Parker <anthony.parker at apple.com <mailto:anthony.parker at apple.com>> wrote:
> 
> 
>> On May 24, 2017, at 12:51 PM, Pavel Yaskevich <pavel.yaskevich at gmail.com <mailto:pavel.yaskevich at gmail.com>> wrote:
>> 
>> Hi Tony,
>> 
>> On Wed, May 24, 2017 at 12:37 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> The way I interpreted SE-110 is that it was suppose to address anonymous arguments. 
>> 
>> Instead of using $0.0, $0.1, One needs to use $0, $1 when there are multiple arguments. 
>> 
>> I was not aware of any implications for explicitly named parameters. 
>> 
>> Perhaps the issue is with the signature of forEach. Does it need to be a nested tuple?
>> 
>> public func forEach(_ body: ((key: Key, value: Value)) throws -> Void) rethrows
>> 
>> Jose is right about this one, since the signature of forEach is a tuple nested into paren it means that `forEach` expects a single argument
>> of a tuple type instead of two arguments, such "tuple argument destructuring" was supported by Swift 3 but after SE-0110 no longer is
>> because type-checker is preserving top level parens in parameters/arguments. 
>> 
>> Best Regards, Pavel.
> 
> Well, frankly, I don’t think we should ship with such a glaring usability regression.
> 
> What’s the mitigation plan? Perhaps we should wholesale revert it until we have time to reconsider the fallout?
> 
> There is a migrator support, and I've made a couple of diagnostic improvements for it, that produce fix-its which are exactly
> what you see in the aforementioned PR. Otherwise, I'd defer to Slava, who was implementor of SE-0110.
> 

The migrator support resulted in the fix-it below, which I believe is a subpar experience for such a core part of using collections and closures in general.

- Tony

>  
> 
> - Tony
> 
>>  
>> 
>> 
>>> On May 24, 2017, at 12:12 PM, Tony Parker via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> Hi everyone,
>>> 
>>> We received a pull request in swift-corelibs-foundation which is apparently in response to a language change for SE-0110.
>>> 
>>> It turns this perfectly reasonable code:
>>> 
>>> -        self.forEach { (keyItem, valueItem) in
>>> 
>>> into this:
>>> 
>>> 
>>> +        self.forEach { (arg) in
>>> +            let (keyItem, valueItem) = arg
>>> 
>>> Is that really the design pattern we want to encourage? What was wrong with the previous code?
>>> 
>>> (https://github.com/apple/swift-corelibs-foundation/pull/995/files <https://github.com/apple/swift-corelibs-foundation/pull/995/files>)
>>> 
>>> - Tony
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170524/98c8f214/attachment.html>