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


(James Froggatt) #1

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

Is it though? Couldn't the current confusing situation of tuple labels in the type system be changed in the exact same way?

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.

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com>

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@public.gmane.org
https://lists.swift.org/mailman/listinfo/swift-evolution

------------- End Message -------------

From James F

···

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org> wrote:


(Austin Zheng) #2

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

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.

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.

···

On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution <swift-evolution@swift.org> wrote:

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com>

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < > swift-evolution-m3FHrko0VLzYtjvyW6yDsg@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@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


(James Froggatt) #3

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

···

On 2 Jul 2016, at 04:22, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution <swift-evolution@swift.org> wrote:

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com>

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < >> swift-evolution-m3FHrko0VLzYtjvyW6yDsg@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@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


(Austin Zheng) #4

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

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.

···

On Jul 1, 2016, at 8:37 PM, James Froggatt <james.froggatt@me.com> wrote:
On 2 Jul 2016, at 04:22, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com <mailto:CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com>>

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < >>> swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org <mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@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@public.gmane.org <mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

------------- End Message -------------

From James F
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(James Froggatt) #5

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

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.

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.

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.

···

On 2 Jul 2016, at 04:46, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 1, 2016, at 8:37 PM, James Froggatt <james.froggatt@me.com> wrote:
On 2 Jul 2016, at 04:22, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 1, 2016, at 8:15 PM, James Froggatt via swift-evolution <swift-evolution@swift.org> wrote:

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com>

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < >>>> swift-evolution-m3FHrko0VLzYtjvyW6yDsg@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@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


(Austin Zheng) #6

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.

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

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.

···

On Jul 1, 2016, at 8:55 PM, James Froggatt <james.froggatt@me.com> wrote:
On 2 Jul 2016, at 04:46, Austin Zheng <austinzheng@gmail.com <mailto:austinzheng@gmail.com>> wrote:

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com <mailto:CAOw3ZebrvO92FRnv2XK1Y_+S2LqYvouo-fM46bPmuFfOF2P1Og@mail.gmail.com>>

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < >>>>> swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org <mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@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@public.gmane.org <mailto:swift-evolution-m3FHrko0VLzYtjvyW6yDsg@public.gmane.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

------------- End Message -------------

From James F
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(James Froggatt) #7

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(_:_:slight_smile:

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:) )

···

On 2 Jul 2016, at 05:03, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 1, 2016, at 8:55 PM, James Froggatt <james.froggatt@me.com> wrote:
On 2 Jul 2016, at 04:46, Austin Zheng <austinzheng@gmail.com> wrote:

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@mail.gmail.com>

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < >>>>>> swift-evolution-m3FHrko0VLzYtjvyW6yDsg@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@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


(James Froggatt) #8

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@me.com> wrote:

On 2 Jul 2016, at 05:03, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 1, 2016, at 8:55 PM, James Froggatt <james.froggatt@me.com> wrote:

On 2 Jul 2016, at 04:46, Austin Zheng <austinzheng@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(_:_:slight_smile:

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@mail.gmail.com>

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < >>>>>>> swift-evolution-m3FHrko0VLzYtjvyW6yDsg@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@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


(Xiaodi Wu) #9

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.froggatt@me.com> wrote:

On 2 Jul 2016, at 05:03, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 1, 2016, at 8:55 PM, James Froggatt <james.froggatt@me.com> wrote:

On 2 Jul 2016, at 04:46, Austin Zheng <austinzheng@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(_:_:slight_smile:

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@mail.gmail.com>

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < > > swift-evolution-m3FHrko0VLzYtjvyW6yDsg@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@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


(James Froggatt) #10

Tuples are inherently interchangable. If you want to avoid this, the safest way is to use a struct.

Labels/naming shouldn't be relied on to provide type information, this is why implicit conformance to protocols is disallowed.

From James F

···

On 2 Jul 2016, at 06:43, Xiaodi Wu <xiaodi.wu@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.froggatt@me.com> wrote:

On 2 Jul 2016, at 05:03, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 1, 2016, at 8:55 PM, James Froggatt <james.froggatt@me.com> wrote:

On 2 Jul 2016, at 04:46, Austin Zheng <austinzheng@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(_:_:slight_smile:

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@mail.gmail.com>

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < >>>>>>>>> swift-evolution-m3FHrko0VLzYtjvyW6yDsg@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@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


(Xiaodi Wu) #11

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.

···

On Sat, Jul 2, 2016 at 1:03 AM, James Froggatt <james.froggatt@me.com> wrote:

From James F

On 2 Jul 2016, at 06:43, Xiaodi Wu <xiaodi.wu@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.froggatt@me.com> wrote:

On 2 Jul 2016, at 05:03, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 1, 2016, at 8:55 PM, James Froggatt <james.froggatt@me.com> wrote:

On 2 Jul 2016, at 04:46, Austin Zheng <austinzheng@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(_:_:slight_smile:

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@mail.gmail.com>

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < >> >> swift-evolution-m3FHrko0VLzYtjvyW6yDsg@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@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


(James Froggatt) #12

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.wu@gmail.com> wrote:

On Sat, Jul 2, 2016 at 1:03 AM, James Froggatt <james.froggatt@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@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.froggatt@me.com> wrote:

On 2 Jul 2016, at 05:03, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 1, 2016, at 8:55 PM, James Froggatt <james.froggatt@me.com> wrote:

On 2 Jul 2016, at 04:46, Austin Zheng <austinzheng@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(_:_:slight_smile:

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@mail.gmail.com>

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < >>>>>>>>>>> swift-evolution-m3FHrko0VLzYtjvyW6yDsg@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@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


(Xiaodi Wu) #13

Those aren't two "interchangeable" types in your example; it's the same
type with two aliases. By contrast, the tuple types `(x: Int, y: Int)` and
`(a: Int, b: Int)` are distinct, as I illustrated above.

You are correct that one of the unique aspects of labeled tuple types would
no longer be so unique if Swift had implicit protocol conformance. It does
not follow that this unique aspect of tuples should be eliminated from the
language.

I choose to use tuples precisely where I want this behavior. For instance,
I don't care if you write `typealias GridCoordinates = (x: Int, y: Int)`
and I write `typealias CartesianCoordinates = ...`; I choose to alias a
tuple type precisely because I want such "interchangeability." But I do
care about the labels being `x` and `y`, and that's where the labeled tuple
comes in.

···

On Sat, Jul 2, 2016 at 1:52 AM James Froggatt <james.froggatt@me.com> wrote:

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.wu@gmail.com> wrote:

On Sat, Jul 2, 2016 at 1:03 AM, James Froggatt <james.froggatt@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@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.froggatt@me.com> wrote:

On 2 Jul 2016, at 05:03, Austin Zheng <austinzheng@gmail.com> wrote:

On Jul 1, 2016, at 8:55 PM, James Froggatt <james.froggatt@me.com> >>> wrote:

On 2 Jul 2016, at 04:46, Austin Zheng <austinzheng@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(_:_:slight_smile:

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@mail.gmail.com>

On Thu, Jun 30, 2016 at 11:26 AM Chris Lattner via swift-evolution < >>> >>> swift-evolution-m3FHrko0VLzYtjvyW6yDsg@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@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