> On May 24, 2017, at 1:01 PM, Pavel Yaskevich <[email protected]> > wrote: > > > > On Wed, May 24, 2017 at 12:57 PM, Tony Parker <[email protected] > <mailto:[email protected]>> wrote: > > >> On May 24, 2017, at 12:51 PM, Pavel Yaskevich <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Tony, >> >> On Wed, May 24, 2017 at 12:37 PM, Jose Cheyo Jimenez via swift-evolution >> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
