> On Jul 1, 2016, at 8:55 PM, James Froggatt <james.frogg...@me.com> wrote: > > > On 2 Jul 2016, at 04:46, Austin Zheng <austinzh...@gmail.com > <mailto:austinzh...@gmail.com>> wrote: > >> >> >> 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.
FWIW, I liked and used tuple splat before it was removed from the language. I thought about it, and I think a lightweight, limited form of tuple application would probably be worth pursuing even before variadic generics go into the language (especially since they are a low-priority item). Perhaps someone could draft a proposal for Swift 3.1. > >>> >>>>> >>>>> 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. I still think it would be a bit odd to have (e.g.) a rejuvenated tuple splatter try to enforce the labels on whatever tuples you pass to it, since those labels would necessarily be tied to a specific function's name, rather than the meaning of the arguments themselves. Do you think there would be too much room for programmer error if such a splatter necessarily took in unlabeled tuples? (Right now any labeled tuple is interchangeable with a non-labeled tuple with the same constituent types...) > > 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. Perhaps I misunderstood your original point. In that case, I apologize. > >>> >>>>> >>>>> ------------ Begin Message ------------ >>>>> Group: gmane.comp.lang.swift.evolution >>>>> MsgID: >>>>> <caow3zebrvo92frnv2xk1y_+s2lqyvouo-fm46bpmuffof2p...@mail.gmail.com >>>>> <mailto: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 >>>>> <mailto: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 >>>>>> >>>>>> <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 >>>>>> <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 >>>>>> <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 >>>>>> <mailto:swift-evolution-m3fhrko0vlzytjvyw6y...@public.gmane.org> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> >>>>> >>>>> >>>>> >>>>> ------------- End Message ------------- >>>>> >>>>> >>>>> >>>>> From James F >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
