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

Fri Jul 1 22:37:45 CDT 2016

> On 2 Jul 2016, at 04:22, Austin Zheng <austinzheng at gmail.com> wrote:
> 
> 
>> On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution <swift-evolution at swift.org> 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

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.

>> 
>> 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.

>> 
>> 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.

>> 
>> ------------ 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160702/bf5b7aa3/attachment.html>