<div dir="ltr"><div>Thank you Austin.<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You asked for engagement with the community, I have provided as such. I did not desire to do so originally,</blockquote><div><br></div><div>Appreciated, I only felt the assumption of "not participating in the original review" == "people not worth talking to" felt a bit patronising, the way it was coming off, as it assumed quite a bit of explicit ill intent. <br></div><br><span class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You use labels when invoking the method using its original name, because
the labels are (almost always) prepositional phases that modify, and as
such only make sense in the context of, the original method name.</blockquote><div><br></div></span>The concern is using the labels when calling a method passed to a function where it is currently explicitly banned. More than reversing the proposal, unless it is the only way to do so, it is finding a way to mandate the argument labels when calling a callback method (or a method saved in a closure type parameter which is essentially the same thing). I do not want to go back to a era of passing two or more arguments to a function without argument labels unless the language never had argument labels to begin with or held them in high regards.<br><br></div>I will consider the rest of your points and re-read the original list before posting in this thread again (unless somebody asks me a question :)).<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 9, 2016 at 6:58 PM, Austin Zheng <span dir="ltr"><<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Apologies, I meant to send this out to the list. If you wish to rebut my points, you are welcome to cc the list with my blessing.<div><br></div><div>Best,</div><div>Austin<div><div class="h5"><br><div><br><div><blockquote type="cite"><div>On Jul 9, 2016, at 10:55 AM, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" target="_blank">panajev@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You asked for engagement with the community, I have provided as such.</blockquote><div><br></div><div>Thank you. <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 9, 2016 at 6:43 PM, Austin Zheng <span dir="ltr"><<a href="mailto:austinzheng@gmail.com" target="_blank">austinzheng@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Jul 9, 2016, at 10:26 AM, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" target="_blank">panajev@gmail.com</a>> wrote:</div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Sorry for not participating, I do blame myself from missing how key that change was. I can blame a very busy period, but that does not really matter.<br><br></div><div>I do think your attitude on this matter is a bit toxic and presumptuous ("people who couldn't be bothered to give feedback") though as if you are looking down on other members of the list for this unforgivable sin. <br>Maybe it is not a matter of giving a damn about helping out the review of the proposal although I can understand the frustration of people disagreeing after the review period, but you should take it less personally as it comes just out of care for the language and ideals even if it may be as flawed as it can be. <br></div></div></div></div></div></blockquote><div><br></div></span><div>You asked for engagement with the community, I have provided as such. I did not desire to do so originally, as my participation in the review thread degenerated into me making the same points again and again to different people, and my participation in this thread would have become more of the same, but here I am.</div><div><br></div><div>As for your other points, they are addressed abundantly in the original thread, both by me and by multiple other people. Please in particular note the delineation between argument labels used to identify the semantic meaning of an argument, and argument labels as prepositional phrases which modify the primary function name.</div><span><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><span><blockquote type="cite"><div><div dir="auto"><div><br></div><div>I imagine scenarios of callbacks, say for an image downloader or something that ought to happen asynchronously, injected in a method, stored, and then used when the asynchronous operation completed one way or the other. </div><div>How does this promote local reasoning so much stressed by Apple itself at WWDC when you have to jump through several hoops to have any idea what the callbacks does or what parameters and in which order it needs them?</div></div></div></blockquote><div><br></div></span><div>If you really want to promote local reasoning, write short methods and look at the function signature, where you can stick labels. Or use the type system or typealiases.</div><div><br></div><div>A better solution might be the compound function names that came up during both the review thread and this thread (e.g. let foo(with:for:) : (Int, Int) -> Bool = blah). Those were going to be added to the original proposal during private review, but were nixed. If someone feels strongly enough about the issue, they should submit a PR for a proposal amendment or a follow-up proposal.</div><span><br></span></div></div></blockquote><div><br></div><div> So, you think having code with multiple parameters passed with obligatory labels mixed with methods where multiple parameters may/have to be passed without argument labels and where the definition of the function and its argument may well be outside of the method body improving clarity and local reasoning or just easy to hand wave away with a "write shorter methods" ? <br></div></div></div></div></div></blockquote><div><br></div></span><div>Yes I do.</div><div><br></div><div>You use labels when invoking the method using its original name, because the labels are (almost always) prepositional phases that modify, and as such only make sense in the context of, the original method name.</div><div><br></div><div>You don't use labels when you erase the original context under which the argument labels were defined by assigning a value of function type to a variable whose name may or may not have any relation to the original method name (again, this was discussed thoroughly in the review thread).</div><div><br></div><div>You can still use labels when defining your closure type arguments to a function or method. Hence, "shorter methods", where the definition of the relevant closure-type parameter is always a glance away.</div><div><br></div><div>I don't know why you are grousing at me, though. Once a proposal enters the review stage (and to be clear, this proposal was introduced on behalf of the core team), its fate is out of the hands of the author. What you *can* do is to write and submit a counterproposal to amend and/or reverse the effects of this one, if you deem it necessary. If your objective at continuing this discussion is to convince the core team to re-review the proposal, I'm sure that writing and submitting a counterproposal will be a far more effective way of accomplishing that goal.</div><span><div><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>If this change simplified the compiler a lot it is a positive, but I think there is a void that need to be addressed as I think that mandatory argument labels are an important part of the language and the work by the core team that carried them over from Objective-C and worked even ore on those highlighting their importance in the road to Swift 3.0.<br></div><div>This situation now calls as much for fixing the discrepancy as much as removing argument labels everywhere else, it unbalances the syntax IMHO.</div></div></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><span><blockquote type="cite"><div><div dir="auto"><div><br></div><div>The benefits to the compiler should be weighed against the negative effects to every day's code and the bugs this may introduce in a safe by default promise language like Swift.</div><br><blockquote type="cite"><div><div><div><blockquote type="cite"><div>On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr">I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once again) away. The community and the core team just finished bikeshedding a huge change to how API's are imported and how labels are used and how important they are and then we do this?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth 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><span><div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="background-color:rgba(255,255,255,0)">Aw. It's really bad that labels are gone for closures at the call site 😢. IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here. </span></div></div></blockquote></div></span>No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been considered.<div><br></div><div>Additionally, those labels may return in the future — although there is a astoundingly long list of features that will be removed because their implementation is flawed, and whose fans have been calmed down with the argument that they'll be re-added in an improved form later ;-)</div></div><br>_______________________________________________<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" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote></div>_______________________________________________<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/mailman/listinfo/swift-evolution</a><br></div></blockquote></span></div><br></div></blockquote></div><br></div></div>
</div></blockquote></span></div><br></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div></div></blockquote></div><br></div>