On Sat, Jul 2, 2016 at 1:03 AM, James Froggatt <james.frogg...@me.com> wrote:
> Tuples are inherently interchangable. If you want to avoid this, the > safest way is to use a struct. > ``` typealias Foo = (a: Int, b: Int) typealias Bar = (c: Int, d: Int) var foo: Foo = (1, 2) var bar: Bar = (3, 4) foo = bar ``` ERROR at line 5, col 7: cannot assign value of type 'Bar' (aka '(c: Int, d: Int)') to type 'Foo' (aka '(a: Int, b: Int)') What do you mean when you say that tuples are inherently interchangeable? What am I not safe from? > Labels/naming shouldn't be relied on to provide type information, > For a tuple type, labels are treated as part of the type; I *do* rely on that. Why do you say that it shouldn't be relied on? > this is why implicit conformance to protocols is disallowed. > I don't follow. From James F > > On 2 Jul 2016, at 06:43, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > What's the basis for your claim that tuples are best passed around without > their labels? If I have `typealias CartesianCoordinates = (x: Double, y: > Double)`, these labels are absolutely meaningful, and I would not want them > to be interchangeable with a hypothetical `typealias PolarCoordinates = (r: > Double, theta: Double)`. Although argument labels are part of the name, > tuple labels are part of the type; there are good reasons for that, and the > two are no longer meant to be similar. This proposal takes us the rest of > the way in clarifying this important distinction. > On Fri, Jul 1, 2016 at 11:52 PM James Froggatt via swift-evolution < > swift-evolution@swift.org> wrote: > >> 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 >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution