[swift-evolution] [Review] SE-0111: Remove type system significance of function argument labels

Sat Jul 2 01:31:45 CDT 2016

On Sat, Jul 2, 2016 at 1:03 AM, James Froggatt <james.froggatt at 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.wu at 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 at 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.froggatt at me.com> wrote:
>>
>>
>> On 2 Jul 2016, at 05:03, Austin Zheng <austinzheng at gmail.com> wrote:
>>
>>
>> On Jul 1, 2016, at 8:55 PM, James Froggatt <james.froggatt at me.com> wrote:
>>
>>
>> On 2 Jul 2016, at 04:46, Austin Zheng <austinzheng at 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-fM46bPmuFfOF2P1Og at mail.gmail.com>
>>
>>
>> On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution <
>>
>> swift-evolution-m3FHrko0VLzYtjvyW6yDsg at 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-m3FHrko0VLzYtjvyW6yDsg at public.gmane.org
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>>
>>
>> ------------- End Message -------------
>>
>>
>>
>>
>> From James F
>>
>> _______________________________________________
>>
>> swift-evolution mailing list
>>
>> swift-evolution at swift.org
>>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160702/70ce97f4/attachment.html>