<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On 2 Jul 2016, at 04:46, Austin Zheng <<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 1, 2016, at 8:37 PM, James Froggatt <<a href="mailto:james.froggatt@me.com" class="">james.froggatt@me.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=""></div><div class="">On 2 Jul 2016, at 04:22, Austin Zheng <<a href="mailto:austinzheng@gmail.com" class="">austinzheng@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class=""></span><br class=""><blockquote type="cite" class=""><span class="">On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">‘If I understand the other discussions regarding the evolution of Swift's function arguments model, the similarity to tuples with labeled components is a historical artifact and now merely coincidental.’</span><br class=""></blockquote><span class=""></span><br class=""><span class="">It's been stated repeatedly in this thread and many others that modeling argument lists as tuples is a non-goal.</span><br class=""><br class=""></div></blockquote><div class=""><br class=""></div><div class="">See <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/023221.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/023221.html</a></div><div class=""><br class=""></div><div class="">It may be a non-goal, but there are reasons relating to generics/variadics that make doing so advantageous. If we're considering moving labels to the container's name, then we're moving to a model where such a thing may be more practical, so it may be appropriate to reassess this.</div></div></div></blockquote><div><br class=""></div><div>This functionality naturally falls out of any decent proposal for variadic generics. I'd rather wait until we can re-add it in a principled manner than stuff yet another @-prefixed special case into the language.</div><br class=""></div></div></blockquote><div><br></div><div>Fair point, but it seems this could stand as a lightweight complement to generics. There seems to be a lack of support for the side of keeping what functionality we already have in this area.</div><br><blockquote type="cite"><div><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Is it though? Couldn't the current confusing situation of tuple labels in the type system be changed in the exact same way?</span><br class=""></blockquote><span class=""></span><br class=""><span class="">Tuple labels work the way you expect them to work: you can't assign an `(a: 1, b: 2)` to a variable of type `(x: Int, y: Int)`. There is nothing confusing about them, at least not in the same way that function types are.</span><br class=""><span class=""></span><br class=""></div></blockquote><div class=""><br class=""></div><div class="">This seems just the same problem as not being able to assign:</div><div class=""><br class=""></div><div class="">(a: Int, b: Int) -> ()</div><div class=""><br class=""></div><div class="">to a type of:</div><div class=""><br class=""></div><div class="">(x: Int, y: Int) -> ()</div><div class=""><br class=""></div><div class="">Functions and tuples are the only uses of labels in the type system I'm aware of. The reasoning for one case seems likely to apply to the other.</div></div></div></blockquote><div><br class=""></div><div>There was a better argument for this sort of thing before the naming guidelines. Swift 2 argument labels often described the semantic value of their arguments. Now you have guidelines which assign non-descriptive prepositional phrases as argument labels. It makes no sense to pull the prepositional phase comprising the argument label (as opposed to the argument name itself) into the type, since that phrase is meaningless outside the context of the primary function name, but the current system (and any based off it) would do just that.</div><div><br class=""></div><div>So no, I don't think the reasoning for tuple labels applies to function argument labels.</div><br class=""></div></div></blockquote><div><br></div><div>Sorry, I meant the reasoning for removing them from the type system. As you said, there was a better argument. I'm observing that this may once again be the case following this change.</div><div><br></div><div>It doesn't help that this went through to the wrong thread, and the quick email I sent to acknowledge this has fallen in a hole somewhere.</div><br><blockquote type="cite"><div><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Or are tuples destined to become nothing more than a historical artifact? If this is the case, then we might as well remove them now.</span><br class=""></blockquote><span class=""></span><br class=""><span class="">Tuples have many, many uses apart from modeling argument lists.</span><br class=""><span class=""></span><br class=""></div></blockquote><div class=""><br class=""></div><div class="">• lightweight structs</div><div class="">• loosely-typed structs</div><div class="">• …as structs</div><div class=""><br class=""></div><div class="">There is no particular reason Void must be modelled as the empty struct, since any non-subclassable Type.self is likewise a singleton.</div><div class=""><br class=""></div><div class="">So there's nothing really making a compelling argument here.</div></div></div></blockquote><div><br class=""></div><div>What? You asked if tuples were going to become a historical artifact? The answer is, "no, they aren't, because they have uses besides modeling argument labels". Void as the empty tuple is irrelevant to the discussion.</div><br class=""></div></div></blockquote><div><br></div><div>I'm not sure how to interpret this, sorry.</div><br><blockquote type="cite"><div><div><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><br class=""><blockquote type="cite" class=""><div class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">------------ Begin Message ------------ </span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Group: gmane.comp.lang.swift.evolution </span><br class=""></blockquote><blockquote type="cite" class=""><span class="">MsgID: <<a href="mailto:CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com" class="">CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com</a>> </span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution <</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org" class="">swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org</a>> wrote:</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Hello Swift community,</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">The review of "SE-0111: Remove type system significance of function</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">argument labels" begins now and runs through July 4. The proposal is</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">available here:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><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></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Reviews are an important part of the Swift evolution process. All reviews</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">should be sent to the swift-evolution mailing list at</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" 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=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">or, if you would like to keep your feedback private, directly to the</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">review manager.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">What goes into a review?</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">The goal of the review process is to improve the proposal under review</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">through constructive criticism and contribute to the direction of Swift.</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">When writing your review, here are some questions you might want to answer</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">in your review:</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">* What is your evaluation of the proposal?</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">+1. I'm in agreement with others in this thread who say that the labels are</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">parts of the *name* of the function, not parts of its *type*. If I</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">understand the other discussions regarding the evolution of Swift's</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">function arguments model, the similarity to tuples with labeled components</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">is a historical artifact and now merely coincidental.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">The analogy to Objective-C here is obvious, where you have selectors</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">instead of functions. The selector is the "name" of the "function" and it</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">contains all of the parts, not just the base name.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Swift function names to me are like German separable verbs. Even when</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">they're split across the sentence with multiple words in-between, the</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">prefix is still considered part of that verb, not a separate word/concept.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">* Is the problem being addressed significant enough to warrant a</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">change to Swift?</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Yes.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">* Does this proposal fit well with the feel and direction of Swift?</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Yes. This feels like a natural follow-up to SE-0021, which allowed the use</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">of argument names to differentiate between overloads with the same argument</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">types at the same positions. To me, this is another admission that the</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">labels are part of the function's *name*.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">* If you have used other languages or libraries with a similar</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">feature, how do you feel that this proposal compares to those?</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Aside from Objective-C mentioned above, the other languages I've used that</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">have named/keyword arguments (like Python) are dynamic languages that treat</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">the incoming argument list as a dictionary; in that case, the language</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">design is significantly different and I can't draw an analogy between them.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">* How much effort did you put into your review? A glance, a quick</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">reading, or an in-depth study?</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">Read the proposal and loosely followed the discussion.</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">More information about the Swift evolution process is available at</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Thank you,</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">-Chris Lattner</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">Review Manager</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">_______________________________________________</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class="">swift-evolution mailing list</span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""><a href="mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org" class="">swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org</a></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" 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=""></blockquote></blockquote><blockquote type="cite" class=""><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">------------- End Message ------------- </span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class=""></span><br class=""></blockquote><blockquote type="cite" class=""><span class="">From James F</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">_______________________________________________</span><br class=""></blockquote><blockquote type="cite" class=""><span class="">swift-evolution mailing list</span><br class=""></blockquote><blockquote type="cite" class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""></blockquote><blockquote type="cite" 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=""></blockquote><span class=""></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></blockquote></body></html>