<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:22, Austin Zheng <<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span><br><blockquote type="cite"><span>On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>‘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></blockquote><span></span><br><span>It's been stated repeatedly in this thread and many others that modeling argument lists as tuples is a non-goal.</span><br><br></div></blockquote><div><br></div><div>See <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/023221.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/023221.html</a></div><div><br></div><div>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><br><blockquote type="cite"><div><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>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></blockquote><span></span><br><span>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><span></span><br></div></blockquote><div><br></div><div>This seems just the same problem as not being able to assign:</div><div><br></div><div>(a: Int, b: Int) -> ()</div><div><br></div><div>to a type of:</div><div><br></div><div>(x: Int, y: Int) -> ()</div><div><br></div><div>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><br><blockquote type="cite"><div><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>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></blockquote><span></span><br><span>Tuples have many, many uses apart from modeling argument lists.</span><br><span></span><br></div></blockquote><div><br></div><div>• lightweight structs</div><div>• loosely-typed structs</div><div>• …as structs</div><div><br></div><div>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><br></div><div>So there's nothing really making a compelling argument here.</div><br><blockquote type="cite"><div><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>------------ Begin Message ------------ </span><br></blockquote><blockquote type="cite"><span>Group: gmane.comp.lang.swift.evolution </span><br></blockquote><blockquote type="cite"><span>MsgID: <<a href="mailto:CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com">CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com</a>> </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution <</span><br></blockquote><blockquote type="cite"><span><a href="mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org">swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>Hello Swift community,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The review of "SE-0111: Remove type system significance of function</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>argument labels" begins now and runs through July 4. The proposal is</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>available here:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md">https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Reviews are an important part of the Swift evolution process. All reviews</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>should be sent to the swift-evolution mailing list at</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>or, if you would like to keep your feedback private, directly to the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>review manager.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>What goes into a review?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The goal of the review process is to improve the proposal under review</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>through constructive criticism and contribute to the direction of Swift.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>When writing your review, here are some questions you might want to answer</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>in your review:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>* What is your evaluation of the proposal?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>+1. I'm in agreement with others in this thread who say that the labels are</span><br></blockquote><blockquote type="cite"><span>parts of the *name* of the function, not parts of its *type*. If I</span><br></blockquote><blockquote type="cite"><span>understand the other discussions regarding the evolution of Swift's</span><br></blockquote><blockquote type="cite"><span>function arguments model, the similarity to tuples with labeled components</span><br></blockquote><blockquote type="cite"><span>is a historical artifact and now merely coincidental.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The analogy to Objective-C here is obvious, where you have selectors</span><br></blockquote><blockquote type="cite"><span>instead of functions. The selector is the "name" of the "function" and it</span><br></blockquote><blockquote type="cite"><span>contains all of the parts, not just the base name.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Swift function names to me are like German separable verbs. Even when</span><br></blockquote><blockquote type="cite"><span>they're split across the sentence with multiple words in-between, the</span><br></blockquote><blockquote type="cite"><span>prefix is still considered part of that verb, not a separate word/concept.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>* Is the problem being addressed significant enough to warrant a</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>change to Swift?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Yes.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>* Does this proposal fit well with the feel and direction of Swift?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Yes. This feels like a natural follow-up to SE-0021, which allowed the use</span><br></blockquote><blockquote type="cite"><span>of argument names to differentiate between overloads with the same argument</span><br></blockquote><blockquote type="cite"><span>types at the same positions. To me, this is another admission that the</span><br></blockquote><blockquote type="cite"><span>labels are part of the function's *name*.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>* If you have used other languages or libraries with a similar</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>feature, how do you feel that this proposal compares to those?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Aside from Objective-C mentioned above, the other languages I've used that</span><br></blockquote><blockquote type="cite"><span>have named/keyword arguments (like Python) are dynamic languages that treat</span><br></blockquote><blockquote type="cite"><span>the incoming argument list as a dictionary; in that case, the language</span><br></blockquote><blockquote type="cite"><span>design is significantly different and I can't draw an analogy between them.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span>* How much effort did you put into your review? A glance, a quick</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>reading, or an in-depth study?</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Read the proposal and loosely followed the discussion.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>More information about the Swift evolution process is available at</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://github.com/apple/swift-evolution/blob/master/process.md">https://github.com/apple/swift-evolution/blob/master/process.md</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Thank you,</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>-Chris Lattner</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>Review Manager</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>_______________________________________________</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org">swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>------------- End Message ------------- </span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>From James F</span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>swift-evolution mailing list</span><br></blockquote><blockquote type="cite"><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br></blockquote><blockquote type="cite"><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></blockquote><span></span><br></div></blockquote></body></html>