<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=""><div class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0);" class=""><br class=""></div></div></div></div></div></div></div><div><blockquote type="cite" class=""><div class="">On 09 Jul 2016, at 15:25, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" class="">panajev@gmail.com</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=""><br class="">Sent from my iPhone</div><div class=""><br class="">On 9 Jul 2016, at 11:31, Taras Zakharko <<a href="mailto:taras.zakharko@uzh.ch" class="">taras.zakharko@uzh.ch</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="">Well, now that function type and function signature are officially separate things,</div></div></blockquote><div class=""><br class=""></div><div class="">I think we may have made a mistake in doing this and the implementation work is not done yet, so we are in time to reconsider things. Processes are not perfect, I do hope nobody gets too offended if I am suggesting we moved too hastily with this proposal without thinking everything through. It can happen.</div></div></div></blockquote><div><br class=""></div><div>You should probably look into the original review thread. The core team made it very clear that the core changes in the compiler were made a long time ago and that the things were working different from what many (including me) thought. There were also some quite compelling reasons for not making label signature part of the type. Specifically, look for email by Jordan Rose</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""> we need means to treat them as separate things. In particular, we need a way to force signatures on closure parameters (and maybe on some variables) while leaving function variables generally signature-agnostic. The proposal is incomplete in this regard. It attempts to solve one problem but actually shifts is elsewhere instead. </div></div></blockquote><div class=""><br class=""></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class="">... hence why I said that this proposal may have been accepted too hastily and if implementing it causes readability/usability/lack of context problems that is just as important as the hopeful benefits to the compiler. The compiler needs to be allowed to do a good job and helped too, but its job is to help us write better code and this proposal does not convince me as achieving that and is considered incomplete by at least a few others in this very thread too.</div></div></div></blockquote><div><br class=""></div><div>The problem is much more complicated than seems at the first glance. Swift designers have opened a huge can of worms by making argument labels first-class features :) This moves the issues from the formal type domain to linguistic domain, and natural language is horribly messy. After some considerations, I believe that the move to separate type and signature is the simplest and probably the most reasonable solution (even though it makes me a bit sad), but we need some additional mechanism for dealing with closure arguments as well. Basically, we need something like a signature type/literal/syntax that enforces function signature, no matter the ‚kind‘ of function (func, variable, closure arg etc.). </div><div><br class=""></div><div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Dr. Taras Zakharko</div><div class=""><br class=""></div><div class=""><a href="mailto:taras.zakharko@uzh.ch" class="">taras.zakharko@uzh.ch</a></div><div class=""><font color="#7d7d7d" class="">IT Officer/Software Development</font></div><div class=""><i class="">---------------------------------------------</i></div><div class="">Department of Comparative Linguistics</div><div class=""><div class="">University of Zurich </div><div class="">Plattenstrasse 54, CH-8032 Zurich</div></div><div class=""><br class=""></div></div></div></div></div></div></div></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="auto" class=""><div class="">I wish the core team or the author of the proposal came to this thread and engaged again with the community. </div></div></blockquote></div><div class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">I am quite sure that they are discussing this internally :) Also, its weekend, let people get some rest!</div></div></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 09 Jul 2016, at 10:56, 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=""><br class="">Sent from my iPhone</div><div class=""><br class="">On 9 Jul 2016, at 00:53, Jon Shier <<a href="mailto:jon@jonshier.com" class="">jon@jonshier.com</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="">While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s autocomplete won’t see them. </div></blockquote><div class=""><br class=""></div><div class="">I wish the core team or the author of the proposal came to this thread and engaged again with the community. </div><div class=""><br class=""></div><div class="">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 class="">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 class=""><br class=""></div><div class="">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 class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 8, 2016, at 6:35 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=""><div dir="ltr" class="">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 class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><span class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><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" class=""><span style="background-color:rgba(255,255,255,0)" class="">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 class=""><br class=""></div><div class="">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 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" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></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=""><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></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></div></blockquote></div><br class=""></body></html>