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