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


(Chris Lattner) #1

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager


(frogcjn) #2

Don't agree with this one.

func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
    print(a, b, c)
}

foo(a: 1, c: 3)

let bar = foo

bar(1, 3) will different than foo(a: 1, c: 3)

···

在 2016年7月7日,11:06,Chris Lattner <clattner@apple.com> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(frogcjn) #3

func needsCallback(callback: (a: Int, b: Int) -> Void) {
    callback(a: 1,b: 2)
}

func needsCallback(callback: (Int, Int) -> Void) {
    callback(1, 2)
}

Is the first one will be forbidden?
So you'd like to keep the second one?

···

在 2016年7月7日,11:06,Chris Lattner via swift-evolution <swift-evolution@swift.org> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tino) #4

I don't remember any "Accepted"-announcement that had such a large thread :wink:
Afair from the original discussion, there is nothing inherently wrong with labels — it's just that they are handled in a suboptimal way.
Assuming that the "board" made an informed decision, it's probably better to accept 0111 and start a proposal for a new implementation of labeled closure parameters… maybe I'm to naive, but I hope that after Swift 3 those labels will return (accompanied by tuple-splat and currying :wink:


(Douglas Gregor) #5

Don't agree with this one.

func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
   print(a, b, c)
}

foo(a: 1, c: 3)

let bar = foo

bar(1, 3) will different than foo(a: 1, c: 3)

bar(1, 3) will result in an error, because “bar” is of type

  (Int, Int, Int) -> Void

Default arguments are associated with function declarations, not function types.

  - Doug

···

On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

在 2016年7月7日,11:06,Chris Lattner <clattner@apple.com> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Goffredo Marocchi) #6

This feels like making the language a lot worse. Lots of time was recently spent bikeshedding methods names and argument labels and this proposal bans labels use in some cases and encourage people not to use them in others.

func needsCallback(callback: (a: Int, b: Int) -> Void) {
    callback(a: 1,b: 2)
}

func needsCallback(callback: (Int, Int) -> Void) {
    callback(1, 2)
}

Is the first one will be forbidden?
So you'd like to keep the second one?

I do not understand why someone would want the second example. A great point of both Objective-C and Swift was enforcing parameter labels use to make the code more readable.

What if that callback were to need width and height? How is that clear which parameter I need to pass in which order?

Considering Swift 3 is our last big chance to break code and fixing the effects of this proposal would break quite a bit of code again... this is a choice it would impact the language for a long time.

···

On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

在 2016年7月7日,11:06,Chris Lattner via swift-evolution <swift-evolution@swift.org> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

_______________________________________________
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


(Goffredo Marocchi) #7

Hey Charlie,

The change you reference and this must work together, I have a hard time accepting that we will have a Swift 3 with this change in and no other change that balances it.

If this

function doItAndLetUsKnow(callback: (Int, Int, Bool) -> ()) {

[...]

    callback(20,40, true)

}

is the style we have to use with callbacks from now on, it will be a major regression I would advise a proposal to stop right now.
The closure passed around and arriving as a callback there gives me NO clue how to send data to it. How is that for local reasoning?
This makes me believe/hope that I am getting it all wrong, so please correct me here :D.

If it is not true, then I am blowing things out of proportion and I apologise for this to everyone on the list.

···

Sent from my iPhone

On 7 Jul 2016, at 08:41, Charlie Monroe <charlie@charliemonroe.net> wrote:

There was a fair proposal by Brent (http://article.gmane.org/gmane.comp.lang.swift.evolution/22939) of adding the labels to the name of the variable rather than adding it to the type. And I agree with that since it simplifies the type system.

Unfortunately, since Swift 3 is making all the code-breaking changed and Brent's counterproposal is additive, it leaves at least a year-long period of not having the parameter labels in closures.

I agree with the change, I don't agree with the timing where it doesn't have a replacement yet.

On Jul 7, 2016, at 9:07 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

This feels like making the language a lot worse. Lots of time was recently spent bikeshedding methods names and argument labels and this proposal bans labels use in some cases and encourage people not to use them in others.

On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

func needsCallback(callback: (a: Int, b: Int) -> Void) {
    callback(a: 1,b: 2)
}

func needsCallback(callback: (Int, Int) -> Void) {
    callback(1, 2)
}

Is the first one will be forbidden?
So you'd like to keep the second one?

I do not understand why someone would want the second example. A great point of both Objective-C and Swift was enforcing parameter labels use to make the code more readable.

What if that callback were to need width and height? How is that clear which parameter I need to pass in which order?

Considering Swift 3 is our last big chance to break code and fixing the effects of this proposal would break quite a bit of code again... this is a choice it would impact the language for a long time.

在 2016年7月7日,11:06,Chris Lattner via swift-evolution <swift-evolution@swift.org> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Charlie Monroe) #8

There was a fair proposal by Brent (http://article.gmane.org/gmane.comp.lang.swift.evolution/22939) of adding the labels to the name of the variable rather than adding it to the type. And I agree with that since it simplifies the type system.

Unfortunately, since Swift 3 is making all the code-breaking changed and Brent's counterproposal is additive, it leaves at least a year-long period of not having the parameter labels in closures.

I agree with the change, I don't agree with the timing where it doesn't have a replacement yet.

···

On Jul 7, 2016, at 9:07 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

This feels like making the language a lot worse. Lots of time was recently spent bikeshedding methods names and argument labels and this proposal bans labels use in some cases and encourage people not to use them in others.

On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

func needsCallback(callback: (a: Int, b: Int) -> Void) {
    callback(a: 1,b: 2)
}

func needsCallback(callback: (Int, Int) -> Void) {
    callback(1, 2)
}

Is the first one will be forbidden?
So you'd like to keep the second one?

I do not understand why someone would want the second example. A great point of both Objective-C and Swift was enforcing parameter labels use to make the code more readable.

What if that callback were to need width and height? How is that clear which parameter I need to pass in which order?

Considering Swift 3 is our last big chance to break code and fixing the effects of this proposal would break quite a bit of code again... this is a choice it would impact the language for a long time.

在 2016年7月7日,11:06,Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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


(frogcjn) #9

l'd like the way of Python to handle the function signature.Assign lost other possibility of that function:

foo(b:c:)
foo(a:c:)
foo(a:b:)
foo(a:)
foo(b:)
foo(c:)
foo()

very weird.

···

在 2016年7月7日,11:36,Douglas Gregor <dgregor@apple.com> 写道:

On Jul 6, 2016, at 8:34 PM, frogcjn@163.com wrote:

so how you call bar and get default values for a, b, c?

You don’t.

why lost default value for that function? it is wired.

Default values aren’t part of a function type. While it is possible to come up with such designs, there is little precedent for them and doing so either drastically limits what kinds of default arguments can be expressed or causes values of function type to become large (so they can encode the computation of the default values).

   - Doug

在 2016年7月7日,11:29,Douglas Gregor <dgregor@apple.com> 写道:

On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

Don't agree with this one.

func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
print(a, b, c)
}

foo(a: 1, c: 3)

let bar = foo

bar(1, 3) will different than foo(a: 1, c: 3)

bar(1, 3) will result in an error, because “bar” is of type

(Int, Int, Int) -> Void

Default arguments are associated with function declarations, not function types.

- Doug

在 2016年7月7日,11:06,Chris Lattner <clattner@apple.com> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Taras Zakharko) #10

I would also be interested in a clarification on this point from Chris or someone else from the core team.

The accepted proposal states that labels are illegal in function types (that is also what I was arguing for towards the end of the review discussion) but at the same time Cris mentions that cosmetic labels are allowed in closure types (which for me is synonymous with function types). So which one is it and how does this change affect closure parameters?

Best,

Taras

···

On 07 Jul 2016, at 10:10, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

Hey Charlie,

The change you reference and this must work together, I have a hard time accepting that we will have a Swift 3 with this change in and no other change that balances it.

If this

function doItAndLetUsKnow(callback: (Int, Int, Bool) -> ()) {

[...]

    callback(20,40, true)

}

is the style we have to use with callbacks from now on, it will be a major regression I would advise a proposal to stop right now.
The closure passed around and arriving as a callback there gives me NO clue how to send data to it. How is that for local reasoning?
This makes me believe/hope that I am getting it all wrong, so please correct me here :D.

If it is not true, then I am blowing things out of proportion and I apologise for this to everyone on the list.

Sent from my iPhone

On 7 Jul 2016, at 08:41, Charlie Monroe <charlie@charliemonroe.net <mailto:charlie@charliemonroe.net>> wrote:

There was a fair proposal by Brent (http://article.gmane.org/gmane.comp.lang.swift.evolution/22939) of adding the labels to the name of the variable rather than adding it to the type. And I agree with that since it simplifies the type system.

Unfortunately, since Swift 3 is making all the code-breaking changed and Brent's counterproposal is additive, it leaves at least a year-long period of not having the parameter labels in closures.

I agree with the change, I don't agree with the timing where it doesn't have a replacement yet.

On Jul 7, 2016, at 9:07 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This feels like making the language a lot worse. Lots of time was recently spent bikeshedding methods names and argument labels and this proposal bans labels use in some cases and encourage people not to use them in others.

On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

func needsCallback(callback: (a: Int, b: Int) -> Void) {
    callback(a: 1,b: 2)
}

func needsCallback(callback: (Int, Int) -> Void) {
    callback(1, 2)
}

Is the first one will be forbidden?
So you'd like to keep the second one?

I do not understand why someone would want the second example. A great point of both Objective-C and Swift was enforcing parameter labels use to make the code more readable.

What if that callback were to need width and height? How is that clear which parameter I need to pass in which order?

Considering Swift 3 is our last big chance to break code and fixing the effects of this proposal would break quite a bit of code again... this is a choice it would impact the language for a long time.

在 2016年7月7日,11:06,Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

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

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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


(Douglas Gregor) #11

I would also be interested in a clarification on this point from Chris or someone else from the core team.

The accepted proposal states that labels are illegal in function types (that is also what I was arguing for towards the end of the review discussion) but at the same time Cris mentions that cosmetic labels are allowed in closure types (which for me is synonymous with function types). So which one is it and how does this change affect closure parameters?

The core team’s intent is that one can add cosmetic labels to function types, but that those labels are not (cannot be) used at the call site, e.g.,

  func foo(fn: (success: Bool) -> Void) {
    fn(true) // note: no ‘success:’ argument label
  }

  func bar(something: Bool) { }

  foo(bar) // okay: labels not considered

The proposal should be updated accordingly so it’s clear for future readers. PR welcome :wink:

  - Doug

···

On Jul 7, 2016, at 3:18 AM, Taras Zakharko via swift-evolution <swift-evolution@swift.org> wrote:

Best,

Taras

On 07 Jul 2016, at 10:10, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hey Charlie,

The change you reference and this must work together, I have a hard time accepting that we will have a Swift 3 with this change in and no other change that balances it.

If this

function doItAndLetUsKnow(callback: (Int, Int, Bool) -> ()) {

[...]

    callback(20,40, true)

}

is the style we have to use with callbacks from now on, it will be a major regression I would advise a proposal to stop right now.
The closure passed around and arriving as a callback there gives me NO clue how to send data to it. How is that for local reasoning?
This makes me believe/hope that I am getting it all wrong, so please correct me here :D.

If it is not true, then I am blowing things out of proportion and I apologise for this to everyone on the list.

Sent from my iPhone

On 7 Jul 2016, at 08:41, Charlie Monroe <charlie@charliemonroe.net <mailto:charlie@charliemonroe.net>> wrote:

There was a fair proposal by Brent (http://article.gmane.org/gmane.comp.lang.swift.evolution/22939) of adding the labels to the name of the variable rather than adding it to the type. And I agree with that since it simplifies the type system.

Unfortunately, since Swift 3 is making all the code-breaking changed and Brent's counterproposal is additive, it leaves at least a year-long period of not having the parameter labels in closures.

I agree with the change, I don't agree with the timing where it doesn't have a replacement yet.

On Jul 7, 2016, at 9:07 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This feels like making the language a lot worse. Lots of time was recently spent bikeshedding methods names and argument labels and this proposal bans labels use in some cases and encourage people not to use them in others.

On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

func needsCallback(callback: (a: Int, b: Int) -> Void) {
    callback(a: 1,b: 2)
}

func needsCallback(callback: (Int, Int) -> Void) {
    callback(1, 2)
}

Is the first one will be forbidden?
So you'd like to keep the second one?

I do not understand why someone would want the second example. A great point of both Objective-C and Swift was enforcing parameter labels use to make the code more readable.

What if that callback were to need width and height? How is that clear which parameter I need to pass in which order?

Considering Swift 3 is our last big chance to break code and fixing the effects of this proposal would break quite a bit of code again... this is a choice it would impact the language for a long time.

在 2016年7月7日,11:06,Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

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

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

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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


(Félix Cloutier) #12

I personally find that { foo(a: $0, c: $1) } is an already simple enough way to solve that problem.

Félix

···

Le 6 juil. 2016 à 20:50:17, Cao, Jiannan via swift-evolution <swift-evolution@swift.org> a écrit :

l'd like the way of Python to handle the function signature.Assign lost other possibility of that function:

foo(b:c:)
foo(a:c:)
foo(a:b:)
foo(a:)
foo(b:)
foo(c:)
foo()

very weird.

在 2016年7月7日,11:36,Douglas Gregor <dgregor@apple.com> 写道:

On Jul 6, 2016, at 8:34 PM, frogcjn@163.com wrote:

so how you call bar and get default values for a, b, c?

You don’t.

why lost default value for that function? it is wired.

Default values aren’t part of a function type. While it is possible to come up with such designs, there is little precedent for them and doing so either drastically limits what kinds of default arguments can be expressed or causes values of function type to become large (so they can encode the computation of the default values).

  - Doug

在 2016年7月7日,11:29,Douglas Gregor <dgregor@apple.com> 写道:

On Jul 6, 2016, at 8:25 PM, Cao, Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

Don't agree with this one.

func foo(a: Int = 0, b: Int = 1, c: Int = 2) {
print(a, b, c)
}

foo(a: 1, c: 3)

let bar = foo

bar(1, 3) will different than foo(a: 1, c: 3)

bar(1, 3) will result in an error, because “bar” is of type

(Int, Int, Int) -> Void

Default arguments are associated with function declarations, not function types.

- Doug

在 2016年7月7日,11:06,Chris Lattner <clattner@apple.com> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
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


(Diego Sánchez) #13

Aw. It's really bad that labels are gone for closures at the call site :cry:. IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here.

I hope I won't come across to many completion(true, false,...) + debugging if someone changes the order of the parameters in some branch and another one is merged adding a new call to the closure type with the old order.

Looks to me that the problem solved may cause more trouble than what was fixed :confused:

Sorry for failing at giving my feedback during the review period :frowning:

···

Sent from my iPhone

On 8 Jul 2016, at 12:15 am, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 7, 2016, at 3:18 AM, Taras Zakharko via swift-evolution <swift-evolution@swift.org> wrote:

I would also be interested in a clarification on this point from Chris or someone else from the core team.

The accepted proposal states that labels are illegal in function types (that is also what I was arguing for towards the end of the review discussion) but at the same time Cris mentions that cosmetic labels are allowed in closure types (which for me is synonymous with function types). So which one is it and how does this change affect closure parameters?

The core team’s intent is that one can add cosmetic labels to function types, but that those labels are not (cannot be) used at the call site, e.g.,

  func foo(fn: (success: Bool) -> Void) {
    fn(true) // note: no ‘success:’ argument label
  }

  func bar(something: Bool) { }

  foo(bar) // okay: labels not considered

The proposal should be updated accordingly so it’s clear for future readers. PR welcome :wink:

  - Doug

Best,

Taras

On 07 Jul 2016, at 10:10, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

Hey Charlie,

The change you reference and this must work together, I have a hard time accepting that we will have a Swift 3 with this change in and no other change that balances it.

If this

function doItAndLetUsKnow(callback: (Int, Int, Bool) -> ()) {

[...]

    callback(20,40, true)

}

is the style we have to use with callbacks from now on, it will be a major regression I would advise a proposal to stop right now.
The closure passed around and arriving as a callback there gives me NO clue how to send data to it. How is that for local reasoning?
This makes me believe/hope that I am getting it all wrong, so please correct me here :D.

If it is not true, then I am blowing things out of proportion and I apologise for this to everyone on the list.

Sent from my iPhone

On 7 Jul 2016, at 08:41, Charlie Monroe <charlie@charliemonroe.net> wrote:

There was a fair proposal by Brent (http://article.gmane.org/gmane.comp.lang.swift.evolution/22939) of adding the labels to the name of the variable rather than adding it to the type. And I agree with that since it simplifies the type system.

Unfortunately, since Swift 3 is making all the code-breaking changed and Brent's counterproposal is additive, it leaves at least a year-long period of not having the parameter labels in closures.

I agree with the change, I don't agree with the timing where it doesn't have a replacement yet.

On Jul 7, 2016, at 9:07 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

This feels like making the language a lot worse. Lots of time was recently spent bikeshedding methods names and argument labels and this proposal bans labels use in some cases and encourage people not to use them in others.

On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

func needsCallback(callback: (a: Int, b: Int) -> Void) {
    callback(a: 1,b: 2)
}

func needsCallback(callback: (Int, Int) -> Void) {
    callback(1, 2)
}

Is the first one will be forbidden?
So you'd like to keep the second one?

I do not understand why someone would want the second example. A great point of both Objective-C and Swift was enforcing parameter labels use to make the code more readable.

What if that callback were to need width and height? How is that clear which parameter I need to pass in which order?

Considering Swift 3 is our last big chance to break code and fixing the effects of this proposal would break quite a bit of code again... this is a choice it would impact the language for a long time.

在 2016年7月7日,11:06,Chris Lattner via swift-evolution <swift-evolution@swift.org> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Charlie Monroe) #14

This hasn't occurred to me until now, but this will also elminate the following (right?):

public typealias XUURLRequestModifier = (request: NSMutableURLRequest) -> Void

Which is really nice since when expanded by Xcode, this automatically offers you the "request" label for the variable so you don't have to name it. Without it, it will simply use the argument type...

···

On Jul 8, 2016, at 1:15 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 7, 2016, at 3:18 AM, Taras Zakharko via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I would also be interested in a clarification on this point from Chris or someone else from the core team.

The accepted proposal states that labels are illegal in function types (that is also what I was arguing for towards the end of the review discussion) but at the same time Cris mentions that cosmetic labels are allowed in closure types (which for me is synonymous with function types). So which one is it and how does this change affect closure parameters?

The core team’s intent is that one can add cosmetic labels to function types, but that those labels are not (cannot be) used at the call site, e.g.,

  func foo(fn: (success: Bool) -> Void) {
    fn(true) // note: no ‘success:’ argument label
  }

  func bar(something: Bool) { }

  foo(bar) // okay: labels not considered

The proposal should be updated accordingly so it’s clear for future readers. PR welcome :wink:

  - Doug

Best,

Taras

On 07 Jul 2016, at 10:10, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hey Charlie,

The change you reference and this must work together, I have a hard time accepting that we will have a Swift 3 with this change in and no other change that balances it.

If this

function doItAndLetUsKnow(callback: (Int, Int, Bool) -> ()) {

[...]

    callback(20,40, true)

}

is the style we have to use with callbacks from now on, it will be a major regression I would advise a proposal to stop right now.
The closure passed around and arriving as a callback there gives me NO clue how to send data to it. How is that for local reasoning?
This makes me believe/hope that I am getting it all wrong, so please correct me here :D.

If it is not true, then I am blowing things out of proportion and I apologise for this to everyone on the list.

Sent from my iPhone

On 7 Jul 2016, at 08:41, Charlie Monroe <charlie@charliemonroe.net <mailto:charlie@charliemonroe.net>> wrote:

There was a fair proposal by Brent (http://article.gmane.org/gmane.comp.lang.swift.evolution/22939) of adding the labels to the name of the variable rather than adding it to the type. And I agree with that since it simplifies the type system.

Unfortunately, since Swift 3 is making all the code-breaking changed and Brent's counterproposal is additive, it leaves at least a year-long period of not having the parameter labels in closures.

I agree with the change, I don't agree with the timing where it doesn't have a replacement yet.

On Jul 7, 2016, at 9:07 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This feels like making the language a lot worse. Lots of time was recently spent bikeshedding methods names and argument labels and this proposal bans labels use in some cases and encourage people not to use them in others.

On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

func needsCallback(callback: (a: Int, b: Int) -> Void) {
    callback(a: 1,b: 2)
}

func needsCallback(callback: (Int, Int) -> Void) {
    callback(1, 2)
}

Is the first one will be forbidden?
So you'd like to keep the second one?

I do not understand why someone would want the second example. A great point of both Objective-C and Swift was enforcing parameter labels use to make the code more readable.

What if that callback were to need width and height? How is that clear which parameter I need to pass in which order?

Considering Swift 3 is our last big chance to break code and fixing the effects of this proposal would break quite a bit of code again... this is a choice it would impact the language for a long time.

在 2016年7月7日,11:06,Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

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

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

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

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

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

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


(Goffredo Marocchi) #15

It feels so odd especially because of the added emphasis by the core team for argument labels for Swift 3 only to have this passed.

What is the pro of not having argument labels in callbacks or functions stored in properties, how does this make for good readability or consistency with instance methods once they are mixed and matched?

completion(true, false,...) + debugging

This kind of methods always was a pain in other languages and a source of annoyance when taking over or reviewing other people's code :(.
If argument labels are not even mandatory in the closure declaration when passed as a method, how is it clear at all what parameters you have to pass and in which order at call site?

···

Sent from my iPhone

On 8 Jul 2016, at 01:49, Diego Sánchez via swift-evolution <swift-evolution@swift.org> wrote:

Aw. It's really bad that labels are gone for closures at the call site :cry:. IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here.

I hope I won't come across to many completion(true, false,...) + debugging if someone changes the order of the parameters in some branch and another one is merged adding a new call to the closure type with the old order.

Looks to me that the problem solved may cause more trouble than what was fixed :confused:

Sorry for failing at giving my feedback during the review period :frowning:

Sent from my iPhone

On 8 Jul 2016, at 12:15 am, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:

On Jul 7, 2016, at 3:18 AM, Taras Zakharko via swift-evolution <swift-evolution@swift.org> wrote:

I would also be interested in a clarification on this point from Chris or someone else from the core team.

The accepted proposal states that labels are illegal in function types (that is also what I was arguing for towards the end of the review discussion) but at the same time Cris mentions that cosmetic labels are allowed in closure types (which for me is synonymous with function types). So which one is it and how does this change affect closure parameters?

The core team’s intent is that one can add cosmetic labels to function types, but that those labels are not (cannot be) used at the call site, e.g.,

  func foo(fn: (success: Bool) -> Void) {
    fn(true) // note: no ‘success:’ argument label
  }

  func bar(something: Bool) { }

  foo(bar) // okay: labels not considered

The proposal should be updated accordingly so it’s clear for future readers. PR welcome :wink:

  - Doug

Best,

Taras

On 07 Jul 2016, at 10:10, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

Hey Charlie,

The change you reference and this must work together, I have a hard time accepting that we will have a Swift 3 with this change in and no other change that balances it.

If this

function doItAndLetUsKnow(callback: (Int, Int, Bool) -> ()) {

[...]

    callback(20,40, true)

}

is the style we have to use with callbacks from now on, it will be a major regression I would advise a proposal to stop right now.
The closure passed around and arriving as a callback there gives me NO clue how to send data to it. How is that for local reasoning?
This makes me believe/hope that I am getting it all wrong, so please correct me here :D.

If it is not true, then I am blowing things out of proportion and I apologise for this to everyone on the list.

Sent from my iPhone

On 7 Jul 2016, at 08:41, Charlie Monroe <charlie@charliemonroe.net> wrote:

There was a fair proposal by Brent (http://article.gmane.org/gmane.comp.lang.swift.evolution/22939) of adding the labels to the name of the variable rather than adding it to the type. And I agree with that since it simplifies the type system.

Unfortunately, since Swift 3 is making all the code-breaking changed and Brent's counterproposal is additive, it leaves at least a year-long period of not having the parameter labels in closures.

I agree with the change, I don't agree with the timing where it doesn't have a replacement yet.

On Jul 7, 2016, at 9:07 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

This feels like making the language a lot worse. Lots of time was recently spent bikeshedding methods names and argument labels and this proposal bans labels use in some cases and encourage people not to use them in others.

On 7 Jul 2016, at 05:21, Cao Jiannan via swift-evolution <swift-evolution@swift.org> wrote:

func needsCallback(callback: (a: Int, b: Int) -> Void) {
    callback(a: 1,b: 2)
}

func needsCallback(callback: (Int, Int) -> Void) {
    callback(1, 2)
}

Is the first one will be forbidden?
So you'd like to keep the second one?

I do not understand why someone would want the second example. A great point of both Objective-C and Swift was enforcing parameter labels use to make the code more readable.

What if that callback were to need width and height? How is that clear which parameter I need to pass in which order?

Considering Swift 3 is our last big chance to break code and fixing the effects of this proposal would break quite a bit of code again... this is a choice it would impact the language for a long time.

在 2016年7月7日,11:06,Chris Lattner via swift-evolution <swift-evolution@swift.org> 写道:

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md

The review of "SE-0111: Remove type system significance of function argument labels " ran from June 30 ... July 4, 2016. The proposal has been *accepted*:

The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.

Thank you to Austin Zheng for driving this discussion forward! I filed SR-2009 to track implementation work on this.

-Chris Lattner
Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tino) #16

Aw. It's really bad that labels are gone for closures at the call site :cry:. IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here.

No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been considered.

Additionally, those labels may return in the future — although there is a astoundingly long list of features that will be removed because their implementation is flawed, and whose fans have been calmed down with the argument that they'll be re-added in an improved form later :wink:


(Pyry Jahkola) #17

Charlie Monroe wrote:

This hasn't occurred to me until now, but this will also elminate the following (right?):

public typealias XUURLRequestModifier = (request: NSMutableURLRequest) -> Void

Which is really nice since when expanded by Xcode, this automatically offers you the "request" label for the variable so you don't have to name it.

As far as I understood, no it won't eliminate that use case, and quite the contrary this is exactly the cosmetic change to the original proposal that the core team wanted to add. So your code above will work, but with the change that a closure `modifier` of type `XUURLRequestModifier` is called like `modifier(req)` from now on and not `modifier(request: req)`.

I think it's often missed in this discussion that there are not one but *two* cases where argument labels (or the lack of them) matter in Swift, and both of cases also affect auto-completion:

1) The first case is when calling a closure (which most often was passed to the current function as an argument). What the accepted proposal SE-0111 did was remove argument labels from those calls in all circumstances:

    func modifyRequest(modifier: XUURLRequestModifier) {
      // This autocompletes without labels as something like:
      modifier(<#request#>)
      // I.e. the cosmetic labels still appear as placeholders, AFAICT.
    }

Most of the time, the code that calls a closure is written once and run multiple times with various blocks, so simple mistakes that argument types won't catch get easily catched in unit tests or when testing the application.

2) The second, and much more common case in application-level code IMO is when passing a closure argument to a library function:

    // This, I think, would autocomplete as:
    frob.modifyRequest { (request: NSMutableURLRequest) -> Void in
      // I.e. now the cosmetic label becomes the default argument name.
    }

So this is where cosmetic labels matter most and nothing changed in this regard in the outcome of SE-0111.

* * *

For people longing to pass labels when *calling* closures, I think you should consider proposing the extended naming syntax idea (or some variant) where an N-argument closure can alternatively be bound to a name with N labels (see https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md):

    // This closure is named `modify(request:)`
    let modify(request:): XUURLModifierRequest = { request in
      ...
    }
    modify(request: req)

    // The argument with label `modifier` is *locally* named `mod(req:)`.
    func example(modifier mod(req:): XUURLModifierRequest) {
      mod(req: someRequest)
    }

    example { request in ... }
    example(modifier: modify(request:))

Note that the local name `req(mod:)` wouldn't need to match the call site (except in type), and they really shouldn't either.

— Pyry


(Goffredo Marocchi) #18

I still say that this is the case where we do take a stand and do ask for
this proposal to be blocked and re-analised, I cannot believe that we are
going to be addingthis kind of incosistency to the language and take
readability/ease of local reasoning (which Apple stressed at the last WWDC
once again) away. The community and the core team just finished
bikeshedding a huge change to how API's are imported and how labels are
used and how important they are and then we do this?

···

On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote:

Aw. It's really bad that labels are gone for closures at the call site :cry:.
IMHO, the same principles that encourage the use of labels for "normal"
function calls should prevail here.

No need to feel bad — if I wasn't ignored (it's hard to notice if this
happens ;-), the argument has been considered.

Additionally, those labels may return in the future — although there is a
astoundingly long list of features that will be removed because their
implementation is flawed, and whose fans have been calmed down with the
argument that they'll be re-added in an improved form later :wink:

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jon Shier) #19

While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s autocomplete won’t see them.

···

On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once again) away. The community and the core team just finished bikeshedding a huge change to how API's are imported and how labels are used and how important they are and then we do this?

On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Aw. It's really bad that labels are gone for closures at the call site :cry:. IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here.

No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been considered.

Additionally, those labels may return in the future — although there is a astoundingly long list of features that will be removed because their implementation is flawed, and whose fans have been calmed down with the argument that they'll be re-added in an improved form later :wink:

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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


(Goffredo Marocchi) #20

While I can see why removing the labels from the type system would be a good idea, I don’t see why calling the functions with labels would be actively prohibited. That’s useful information for the developer to have, and if the compiler doesn’t know them in some way, you can be assured Xcode’s autocomplete won’t see them.

I wish the core team or the author of the proposal came to this thread and engaged again with the community.

I imagine scenarios of callbacks, say for an image downloader or something that ought to happen asynchronously, injected in a method, stored, and then used when the asynchronous operation completed one way or the other.
How does this promote local reasoning so much stressed by Apple itself at WWDC when you have to jump through several hoops to have any idea what the callbacks does or what parameters and in which order it needs them?

The benefits to the compiler should be weighed against the negative effects to every day's code and the bugs this may introduce in a safe by default promise language like Swift.

···

Sent from my iPhone

On 9 Jul 2016, at 00:53, Jon Shier <jon@jonshier.com> wrote:

On Jul 8, 2016, at 6:35 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

I still say that this is the case where we do take a stand and do ask for this proposal to be blocked and re-analised, I cannot believe that we are going to be addingthis kind of incosistency to the language and take readability/ease of local reasoning (which Apple stressed at the last WWDC once again) away. The community and the core team just finished bikeshedding a huge change to how API's are imported and how labels are used and how important they are and then we do this?

On Fri, Jul 8, 2016 at 10:22 AM, Tino Heth via swift-evolution <swift-evolution@swift.org> wrote:

Aw. It's really bad that labels are gone for closures at the call site :cry:. IMHO, the same principles that encourage the use of labels for "normal" function calls should prevail here.

No need to feel bad — if I wasn't ignored (it's hard to notice if this happens ;-), the argument has been considered.

Additionally, those labels may return in the future — although there is a astoundingly long list of features that will be removed because their implementation is flawed, and whose fans have been calmed down with the argument that they'll be re-added in an improved form later :wink:

_______________________________________________
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