> On Jul 1, 2016, at 8:37 PM, James Froggatt <[email protected]> wrote: > > > On 2 Jul 2016, at 04:22, Austin Zheng <[email protected] > <mailto:[email protected]>> wrote: > >> >>> On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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 > > <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. > >>> >>> 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. > >>> >>> 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. > >>> >>> ------------ 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 < >>> [email protected] >>> <mailto:[email protected]>> 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 >>>> [email protected] >>>> <mailto:[email protected]> >>>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
