typealias Point = (x: Int, y: Int)
typealias Dimensions = (x: Int, y: Int)
let point: Point = (x: 5, y: 5)
let dimensions = point
Fundamentally different concepts may have labels happen to be the same. Structs
protect against this conversion, tuples don't.
Explicit protocol conformance is justified in this way:
protocol GridPoint {
var x: Int {get}
var y: Int {get}
}
protocol Box {
associatedtype UnitType
var x: UnitType {get}
var y: UnitType {get}
var z: UnitType {get}
}
GridPoints obviously shouldn't be Boxes, but with implicit conformance, every
Box would be a GridPoint.
From James F
> On 2 Jul 2016, at 07:31, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
>> 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
