<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 30 Jun 2016, at 22:38, Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">You might like the alternative I added (<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>). It basically goes the other way: keep the semantic significance of labels, and make them mean something by prohibiting converting between different function types with the same types but different labels.</div></div></blockquote><div><br class=""></div>Yes, thats what I would vote for! I would also add the possibility of explicitly converting between different labels, as long as the types match, e.g.:</div><div><br class=""></div><div><pre style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 13.600000381469727px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(51, 51, 51);" class="">battingAveragePredicate <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> sinkBattleship as (<span style="font-size: 13.600000381469727px;" class="">(ofHits: </span><span class="pl-c1" style="font-size: 13.600000381469727px; box-sizing: border-box; color: rgb(0, 134, 179);">Int</span><span style="font-size: 13.600000381469727px;" class="">, forRuns: </span><span class="pl-c1" style="font-size: 13.600000381469727px; box-sizing: border-box; color: rgb(0, 134, 179);">Int</span><span style="font-size: 13.600000381469727px;" class="">) </span><span class="pl-k" style="font-size: 13.600000381469727px; box-sizing: border-box; color: rgb(167, 29, 93);">-&gt;</span><span style="font-size: 13.600000381469727px;" class=""> </span><span class="pl-c1" style="font-size: 13.600000381469727px; box-sizing: border-box; color: rgb(0, 134, 179);">Bool)</span></pre><div class=""><br class=""></div><div class="">or&nbsp;</div><div class=""><br class=""></div><div class=""><pre style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 13.600000381469727px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(51, 51, 51);" class="">battingAveragePredicate <span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">=</span> sinkBattleship as typeof(battlingAveragePredicate)</pre><div class=""><br class=""></div></div><div class=""><br class=""></div><div class="">(whatever the correct syntax for this would be).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Best,&nbsp;</div><div class=""><br class=""></div><div class="">&nbsp;t.&nbsp;</div><div class=""><br class=""></div><div><br class=""></div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 30, 2016 at 1:36 PM, Taras Zakharko <span dir="ltr" class="">&lt;<a href="mailto:taras.zakharko@uzh.ch" target="_blank" class="">taras.zakharko@uzh.ch</a>&gt;</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=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On 30 Jun 2016, at 22:11, Austin Zheng &lt;<a href="mailto:austinzheng@gmail.com" target="_blank" class="">austinzheng@gmail.com</a>&gt; wrote:</div><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">As for the label semantics, Swift's current behavior is actively misleading, please see the example in the prior email. There are no meaningful semantics in the label, because implicit conversion between differently-labeled function types means that there is no way to usefully enforce these invariants to begin with.</div></div></div></blockquote><div class=""><br class=""></div></span><div class="">That is a good point. I admit to not knowing this (I strongly expected that labels would be semantically meaningful). But what exactly is the status of the argument labels than in Swift? Just a documentation device &nbsp;for the programmer and a &nbsp;hint for the compiler to do function dispatch? But if the compiler indeed does dispatch on argument labels, then they are not completely void of semantics, are they?&nbsp; As I mentioned before, I think the problem here is much deeper.&nbsp;</div><div class=""><br class=""></div><div class="">The state of affairs I would prefer is something along these lines:</div><div class=""><br class=""></div><div class="">1. Labels are semantically meaningful</div><div class="">2. There is an explicit casting system for function signatures</div><div class="">3. This casting system should be in close correspondence to tuples. The "function argument lists look sort of like tuples“ is a very compelling reason actually, because of the principle of the least surprise. If I have two things in the language that look very similar, then its very confusing if they &nbsp;exhibit very different behaviour. Again, I am not proposing that one goes back to model functions in terms of tuples. But as long as there is a surface resemblance (and an obvious morphisms between the two), at least some aspects of their design should be kept in sync.&nbsp;</div><div class=""><br class=""></div><div class="">But again, this touches on some deep design decisions for the language, so I — as an amateur — don’t feel in my plate discussing this here. I believe that there currently might be some inconsistencies in the language design that should be sealed with (but maybe they are no inconsistencies at all and I simply have false expectations).&nbsp;</div><div class=""><br class=""></div><div class="">Best,&nbsp;</div><span class="HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">&nbsp;Taras</div></font></span><div class=""><div class="h5"><br class=""><blockquote type="cite" class=""><div class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Jun 30, 2016 at 12:42 PM, Taras Zakharko via swift-evolution <span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</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=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On 30 Jun 2016, at 21:20, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br class=""><div class=""><div dir="ltr" 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=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 30, 2016 at 2:14 PM, Taras Zakharko via swift-evolution<span class="">&nbsp;</span><span dir="ltr" class="">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;</span><span class="">&nbsp;</span>wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br class="">&gt; On 30 Jun 2016, at 20:26, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:<br class="">&gt;<br class="">&gt; Hello Swift community,<br class="">&gt;<br class="">&gt; The review of "SE-0111: Remove type system significance of function argument labels" begins now and runs through July 4. The proposal is available here:<br class="">&gt;<br class="">&gt;&nbsp; &nbsp; &nbsp; &nbsp;<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md" rel="noreferrer" target="_blank" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md</a><br class="">&gt;<br class=""></span><span class="">&gt;&nbsp; &nbsp; &nbsp; &nbsp;* What is your evaluation of the proposal?<br class=""><br class=""></span>-1<br class=""><span class=""><br class="">&gt;&nbsp; &nbsp; &nbsp; &nbsp;* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""><br class=""></span>Yes, but I do not think that the proposed solution is the correct one. Rather, one should aim for designing a proper tuple type. Right now, tuples seem more like an afterthought even though they play a significant role in the language.&nbsp; Proper tuple casting/extensions/tuple algebra will solve the issues pointed out in this proposal, among other useful applications.<br class=""></blockquote><div class=""><br class=""></div><div class="">Taras, I don't believe this proposal touches tuples in any way. IIUC, argument lists are no longer tuples and have not been for a long time, and there is no intention on the part of the core team to return to that state of affairs.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Still, there is a clear correspondence between tuples and argument lists. I though that the model of functions as maps from tuples to tuples was very elegant, but I understand why this model was dropped. However tuples seem to be somehow misplaced right now, and this fact resonates through the entire language system (function types, enums, pattern matching etc.). I think one should stop and reconsider tuple status first to get a sense of a ‚grand strategy‘ for Swift. I am worried that small changes like this proposal attempt to deal with the ripples cast by a much deeper problem instead of the problem itself. As far as I am considered, there are two basic options. Either say, well, tuples were a nice idea, but it doesn’t really work out — and then consistently apply this to the entire language. Or, reinstate that tuples are a modelling construct on which a lot of language concepts are based and try to fix the underlaying limitations. Function arguments don’t need to be tuples formally. However, why not have a casting system that allows one to transform between function signatures and tuple types?&nbsp; That would certainly solve the deficients Swift is experiencing now as well as allow greater flexibility in the future.&nbsp;</div><div class=""><br class=""></div><div class="">And orthogonally to the tuple topic, I think that argument labels carry meaningful semantics and are much more than just cosmetic devices. Accepting this proposal would make the language weird. The deeper connection between the semantics of the argument list and the exposed type would be disturbed.&nbsp;</div><div class=""><br class=""></div><div class="">Hope any of this has made any sense :)</div><span class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" 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=""><div class="gmail_extra"><div class="gmail_quote"><div class="">&nbsp;</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br class="">&gt;&nbsp; &nbsp; &nbsp; &nbsp;* Does this proposal fit well with the feel and direction of Swift?<br class=""><br class=""></span>I do not believe so<br class=""><span class=""><br class="">&gt;&nbsp; &nbsp; &nbsp; &nbsp;* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class="">&gt;&nbsp; &nbsp; &nbsp; &nbsp;* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""><br class=""></span>A glance<br class=""><div class=""><div class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" 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></div></div></blockquote></div></div></div></div></blockquote></span></div><br class=""></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" 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>
</div></blockquote></div></div></div><br class=""></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></body></html>