<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 7, 2016, at 3:18 AM, Taras Zakharko via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I would also be interested in a clarification on this point from Chris or someone else from the core team. </div><div class=""><br class=""></div><div class="">The accepted proposal states that labels are illegal in function types (that is also what I was arguing for towards the end of the review discussion) but at the same time Cris mentions that cosmetic labels are allowed in closure types (which for me is synonymous with function types). So which one is it and how does this change affect closure parameters?</div></div></div></blockquote><div><br class=""></div>The core team’s intent is that one can add cosmetic labels to function types, but that those labels are not (cannot be) used at the call site, e.g.,</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func foo(fn: (success: Bool) -> Void) {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> fn(true) // note: no ‘success:’ argument label</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>func bar(something: Bool) { }</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>foo(bar) // okay: labels not considered</div><div><br class=""></div><div>The proposal should be updated accordingly so it’s clear for future readers. PR welcome ;)</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Best, </div><div class=""><br class=""></div><div class=""> Taras</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 07 Jul 2016, at 10:10, Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Hey Charlie,</div><div class=""><br class=""></div><div class="">The change you reference and this must work together, I have a hard time accepting that we will have a Swift 3 with this change in and no other change that balances it.</div><div class=""><br class=""></div><div class="">If this</div><div class=""><br class=""></div><div class="">function doItAndLetUsKnow(callback: (Int, Int, Bool) -> ()) {</div><div class=""><br class=""></div><div class="">[...]</div><div class=""><br class=""></div><div class=""> callback(20,40, true)</div><div class=""><br class=""></div><div class="">}</div><div class=""><br class=""></div><div class="">is the style we have to use with callbacks from now on, it will be a major regression I would advise a proposal to stop right now.</div><div class="">The closure passed around and arriving as a callback there gives me NO clue how to send data to it. How is that for local reasoning?</div><div class="">This makes me believe/hope that I am getting it all wrong, so please correct me here :D.</div><div class=""><br class=""></div><div class="">If it is not true, then I am blowing things out of proportion and I apologise for this to everyone on the list.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Sent from my iPhone</div><div class=""><br class="">On 7 Jul 2016, at 08:41, Charlie Monroe <<a href="mailto:charlie@charliemonroe.net" class="">charlie@charliemonroe.net</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div class="">There was a fair proposal by Brent (<a href="http://article.gmane.org/gmane.comp.lang.swift.evolution/22939" class="">http://article.gmane.org/gmane.comp.lang.swift.evolution/22939</a>) of adding the labels to the name of the variable rather than adding it to the type. And I agree with that since it simplifies the type system.</div><div class=""><br class=""></div><div class="">Unfortunately, since Swift 3 is making all the code-breaking changed and Brent's counterproposal is additive, it leaves at least a year-long period of not having the parameter labels in closures.</div><div class=""><br class=""></div><div class="">I agree with the change, I don't agree with the timing where it doesn't have a replacement yet.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On Jul 7, 2016, at 9:07 AM, Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">This feels like making the language a lot worse. Lots of time was recently spent bikeshedding methods names and argument labels and this proposal bans labels use in some cases and encourage people not to use them in others.<br class=""></div><div class=""><br class="">On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=gb2312" class=""><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'Fira Code';" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #0433ff" class="">func</span><span style="font-variant-ligatures: no-common-ligatures" class=""> needsCallback(callback: (a: </span><span style="font-variant-ligatures: no-common-ligatures; color: #3495af" class="">Int</span><span style="font-variant-ligatures: no-common-ligatures" class="">, b: </span><span style="font-variant-ligatures: no-common-ligatures; color: #3495af" class="">Int</span><span style="font-variant-ligatures: no-common-ligatures" class="">) -> </span><span style="font-variant-ligatures: no-common-ligatures; color: #3495af" class="">Void</span><span style="font-variant-ligatures: no-common-ligatures" class="">) {</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'Fira Code';" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> callback(a: 1,b: 2)</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'Fira Code';" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">}</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'Fira Code'; min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""></span><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'Fira Code'; min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""></span><br class=""></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'Fira Code';" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #0433ff" class="">func</span><span style="font-variant-ligatures: no-common-ligatures" class=""> needsCallback(callback: (</span><span style="font-variant-ligatures: no-common-ligatures; color: #3495af" class="">Int</span><span style="font-variant-ligatures: no-common-ligatures" class="">, </span><span style="font-variant-ligatures: no-common-ligatures; color: #3495af" class="">Int</span><span style="font-variant-ligatures: no-common-ligatures" class="">) -> </span><span style="font-variant-ligatures: no-common-ligatures; color: #3495af" class="">Void</span><span style="font-variant-ligatures: no-common-ligatures" class="">) {</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'Fira Code';" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> callback(1, 2)</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'Fira Code';" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">}</span></div></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'Fira Code';" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'Fira Code';" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">Is the first one will be forbidden?</span></div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: 'Fira Code';" class=""><span style="font-variant-ligatures: no-common-ligatures" class="">So you'd like to keep the second one?</span></div></div></blockquote><div class=""><br class=""></div><div class="">I do not understand why someone would want the second example. A great point of both Objective-C and Swift was enforcing parameter labels use to make the code more readable. </div><div class=""><br class=""></div><div class="">What if that callback were to need width and height? How is that clear which parameter I need to pass in which order?</div><div class=""><br class=""></div><div class="">Considering Swift 3 is our last big chance to break code and fixing the effects of this proposal would break quite a bit of code again... this is a choice it would impact the language for a long time. </div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">在 2016年7月7日，11:06，Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> 写道：</div><br class="Apple-interchange-newline"><div class=""><div class="">Proposal Link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md</a><br class=""><br class="">The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:<br class=""><br class="">The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.<br class=""><br class="">Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.<br class=""><br class="">-Chris Lattner<br class="">Review Manager<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>