<div dir="ltr"><div class="gmail_extra">Hi Tony,</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Wed, May 24, 2017 at 12:37 PM, Jose Cheyo Jimenez via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">The way I interpreted SE-110 is that it was suppose to address anonymous arguments. <div><br></div><div>Instead of using $0.0, $0.1, One needs to use $0, $1 when there are multiple arguments. <div><br></div><div>I was not aware of any implications for explicitly named parameters. </div><div><br></div><div>Perhaps the issue is with the signature of forEach. Does it need to be a nested tuple?</div><div><br></div><div>public func forEach(_ body: ((key: Key, value: Value)) throws -> Void) <wbr>rethrows<br></div></div></div></blockquote><div><br></div><div>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</div><div>of a tuple type instead of two arguments, such "tuple argument destructuring" was supported by Swift 3 but after SE-0110 no longer is</div><div>because type-checker is preserving top level parens in parameters/arguments. </div><div><br></div><div>Best Regards, Pavel.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><div><br></div><div><br><div><blockquote type="cite"><div><div class="gmail-h5"><div>On May 24, 2017, at 12:12 PM, Tony Parker via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="gmail-m_6296259074267002623Apple-interchange-newline"></div></div><div><div><div class="gmail-h5"><div style="word-wrap:break-word">Hi everyone,<div><br></div><div>We received a pull request in swift-corelibs-foundation which is apparently in response to a language change for SE-0110.</div><div><br></div><div>It turns this perfectly reasonable code:</div><div><div><br></div><div><font face="Menlo">- self.forEach { (keyItem, valueItem) in</font></div><div><br></div><div>into this:</div><div><br></div><div><br><font face="Menlo">+ self.forEach { (arg) in<br>+ let (keyItem, valueItem) = arg<br></font><br>Is that really the design pattern we want to encourage? What was wrong with the previous code?</div><div><br></div><div>(<a href="https://github.com/apple/swift-corelibs-foundation/pull/995/files" target="_blank">https://github.com/apple/<wbr>swift-corelibs-foundation/<wbr>pull/995/files</a>)</div></div><div><br></div><div>- Tony</div><div><br></div></div></div></div>______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></div></div></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>