<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 10, 2016, at 10:53 PM, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 10, 2016, at 10:30 PM, David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div 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=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><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></div></blockquote><div class=""><br class=""></div><div class="">I'm not inclined to spend time engaging with people who couldn't be bothered to give feedback during the week-long official review period.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Not all people "couldn’t be bothered” but had life events, such as moving across states with four kids, that prevented them from being able to engage during the official review period. </div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I hope your move went smoothly. More generally, there will always be people with good reasons for not being able to participate in the review process, but the procedure is set: one week of formal discussion, followed by a decision by the core team. If a proposal should be re-reviewed or amended, someone should submit (or at least draft) a follow-up proposal; none of the other proposals that have been accepted have been taken up for re-review by the core team based merely on reviews that were submitted after the review period ended (and there have been at least a few whose acceptance was very controversial).</div></div></div></div></blockquote><div><br class=""></div><div>Sure, the review period is fine. I think it’s unreasonable to say that questions, clarifications, or feedback should simply be ignored because it’s outside of the review window. If the feature is implemented and checked in, fine, but we’re still aways from there.</div><div><br class=""></div><div>Regardless, my feedback was more about clarification on what is actually being changed for the workflow because I found no real answers in the proposal or the thread. I found where some concerns were made, but no real solutions to those concerns. Maybe I just overlooked them.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">I’ve read through all of the posts that I see in my mailbox regarding this topic and I’ve yet to see any real answer to the concerns of tooling, typealias usage, closures, and code readability and maintainability concerns under this new proposal. This is the closest I’ve seen (from Douglas Gregor a few days ago):</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">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.,</blockquote><div class=""><br class=""></div><div class="">Do you have specific post in mind that addresses the these concerns? Maybe I’m just missing them, but I really don’t see those addressed and they are not mentioned in the proposal at all.</div><div class=""><br class=""></div><div class="">Let’s say I want to model a problem regarding some library functions that work with resizing some image type. Today, if I did that, the tooling would give me auto-completion for all of the parameter labels and the code is very legible. </div><div class=""><br class=""></div><div class="">Note that both `original` and `resized` get auto-completed for us here. This provides great code clarity and insights. This is also self-documenting code.</div><div class=""><br class=""></div><div class="">However, under this proposal as accepted (as I understand it), we are left with this:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">func</span><span style="font-variant-ligatures: no-common-ligatures" class=""> doResizeC(image: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Image</span><span style="font-variant-ligatures: no-common-ligatures" class="">, completed: (</span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Image</span><span style="font-variant-ligatures: no-common-ligatures" class="">, </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Image</span><span style="font-variant-ligatures: no-common-ligatures" class="">) -> </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Void</span><span style="font-variant-ligatures: no-common-ligatures" class="">) {</span></div><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">let</span><span style="font-variant-ligatures: no-common-ligatures" class=""> newData = image.data</span></div><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">let</span><span style="font-variant-ligatures: no-common-ligatures" class=""> newSize = image.size</span></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">You can still have labels in the type: `completed: (original: Image, resized: Image)`.</div></div></div></blockquote><div><br class=""></div><div>Labels that aren’t enforced or checked by the compiler are effectively worthless; they may as well be comments. This makes those labels allowed on typealiases equally as effective.</div><div class=""><br class=""></div><div class="">I also find it extremely strange that these labels will be allowed as source code that can never be verified or used in other places. It seems we are simply trading one set of inconsistencies for another.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><div style="margin: 0px; line-height: normal; min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""></span><br class=""></div><div style="margin: 0px; line-height: normal; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""> </span><span style="font-variant-ligatures: no-common-ligatures" class="">// do some work that's really slow...</span></div><div style="margin: 0px; line-height: normal; min-height: 13px;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><br class="webkit-block-placeholder"></div><div style="margin: 0px; line-height: normal;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> completed(image, Image(data: newData, size: newSize))</span></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">This is definitely a problem. I am considering writing a follow-up proposal that would allow for compound naming of values of function type, which would alleviate this problem: `let foo(x:y:) : (Int, Int) -> Void`, which was brought up a couple of times during the review thread. (This was going to be part of the original proposal, but was removed for various reasons.)</div></div></div></blockquote></div><br class=""><div class="">Which just gets you back to this syntax for closures:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">func</span><span style="font-variant-ligatures: no-common-ligatures" class=""> doResizeB(image: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Image</span><span style="font-variant-ligatures: no-common-ligatures" class="">, completed: (original: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Image</span><span style="font-variant-ligatures: no-common-ligatures" class="">, resized: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Image</span><span style="font-variant-ligatures: no-common-ligatures" class="">) -> </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Void</span><span style="font-variant-ligatures: no-common-ligatures" class="">)</span></div></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class="">Unless you really want to try and get parameter name syntax changed to match your example:</span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">func</span><span style="font-variant-ligatures: no-common-ligatures" class=""> doResizeB(image: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Image</span><span style="font-variant-ligatures: no-common-ligatures" class="">, completed(original:resized:): (</span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Image</span><span style="font-variant-ligatures: no-common-ligatures" class="">, </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Image</span><span style="font-variant-ligatures: no-common-ligatures" class="">) -> </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">Void</span><span style="font-variant-ligatures: no-common-ligatures" class="">)</span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class="">Or maybe something else… I guess I will have to wait for the proposal.</div><div class=""><br class=""></div><div class="">-David</div></span></div></body></html>