> A parameter list of (inout Int, @noescape Int -> ()) is just a ‘tuple + > annotations’ relevant to use in parameter lists. If you can restrict this > pseudo-type to the appropriate context, like we are heading towards with > disallowing ImplicityUnwrappedOptional in function signatures, why not > restrict certain type annotations to only occur in function signatures?
Effectively the presence of parameter annotations in a tuple make it a ‘splat-only tuple’. From James F > On 2 Jul 2016, at 05:38, James Froggatt <james.frogg...@me.com> wrote: > > >> On 2 Jul 2016, at 05:03, Austin Zheng <austinzh...@gmail.com> wrote: >> >> >>> 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> 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. >> > > This is why I support keeping what existing semantics we can, rather than > stripping it all out only to reimplement it as soon as people realise it's > missing. > > The distinction between (Int, Int) and ((Int, Int)) seems trivial. > > A parameter list of (inout Int, @noescape Int -> ()) is just a ‘tuple + > annotations’ relevant to use in parameter lists. If you can restrict this > pseudo-type to the appropriate context, like we are heading towards with > disallowing ImplicityUnwrappedOptional in function signatures, why not > restrict certain type annotations to only occur in function signatures? > >>> >>>>> >>>>>>> >>>>>>> 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...) >> > > My idea is that if we switch to using: > > let functionType(a:b:) = add(_:_:) > > then it make sense to have tuples match this syntax, to avoid having two > similar naming mechanisms with very different semantics: > > let values(x:y:) = (1, 2) > > Like a function's argument labels are rarely sensible out of context, tuples > are best passed around without considering their labels. For example: > > let name: (first: String, last: String) = … > > name.first //clear > > func join(stringTuple: (String, String)) > > join(stringTuple: name) //is this allowed? > > > At this point (generally as soon as the tuple leaves the context of its > containing variable), the original parameter labels are meaningless. > Alternatively: > > > let name(first:last:): (String, String) = … > > name.first //still clear > > join(name) //clearly allowed, since the labels are not part of the type > > > With this, if I understand you properly, argument names wouldn't be present > in the type system to begin with, so calling the result of a splatter would > be predictable: > > join(a: String, b: String) > > let splatted: ((String, String)) -> () = splat(join) // or splat( join(a:b:) ) > > splatted(name) // or splatted( name(first:last:) ) > >>> >>> 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> >>>>>>> >>>>>>> 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
