Argument labels in callbacks


(Franklin Schrans) #1

Hi,

When SE-0111 <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md> was approved, I noticed the implication it had when using closures as callbacks:

Writing
   func foo(completion: (success: Bool) -> Void) {
     completion(success: true)
   }

is no longer possible, because function types can’t have argument labels anymore, and the function has to be written:
   func foo(completion: (Bool) -> Void) {
     completion(true)
   }

which doesn’t look very nice, especially as the number of the arguments increases.

After talking to Chris Lattner about this, he referred me to this <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html> email.
I was wondering if there's been any further work or plans in restoring the use of argument labels in closures.

- Franklin


(Goffredo Marocchi) #2

I am quite interested in this as well, thanks for bringing it up! It was quite disappointing to fall back to multi argument method calls without labels as it was going against the emphasis on the value of labels in the language as well as decreasing readability of what is supposed to be self documenting code.

···

Sent from my iPhone

On 22 Feb 2017, at 08:36, Franklin Schrans via swift-evolution <swift-evolution@swift.org> wrote:

Hi,

When SE-0111 was approved, I noticed the implication it had when using closures as callbacks:

Writing
   func foo(completion: (success: Bool) -> Void) {
     completion(success: true)
   }

is no longer possible, because function types can’t have argument labels anymore, and the function has to be written:
   func foo(completion: (Bool) -> Void) {
     completion(true)
   }

which doesn’t look very nice, especially as the number of the arguments increases.

After talking to Chris Lattner about this, he referred me to this email.
I was wondering if there's been any further work or plans in restoring the use of argument labels in closures.

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


(Charlie Monroe) #3

This was pointed out during the discussions surrounding this proposal and it was agreed that the type simplification was important.

There were several suggestions how to bring this back using different features - e.g. compound names that would contain the labels. For example:

let callback(success:error:): (Bool, Error?) -> Void = ...
callback(success: true, error: nil)

This way the type itself wouldn't contain the label information, but the name of the variable would.

···

On Feb 22, 2017, at 9:41 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

I am quite interested in this as well, thanks for bringing it up! It was quite disappointing to fall back to multi argument method calls without labels as it was going against the emphasis on the value of labels in the language as well as decreasing readability of what is supposed to be self documenting code.

Sent from my iPhone

On 22 Feb 2017, at 08:36, Franklin Schrans via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi,

When SE-0111 <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md> was approved, I noticed the implication it had when using closures as callbacks:

Writing
   func foo(completion: (success: Bool) -> Void) {
     completion(success: true)
   }

is no longer possible, because function types can’t have argument labels anymore, and the function has to be written:
   func foo(completion: (Bool) -> Void) {
     completion(true)
   }

which doesn’t look very nice, especially as the number of the arguments increases.

After talking to Chris Lattner about this, he referred me to this <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html> email.
I was wondering if there's been any further work or plans in restoring the use of argument labels in closures.

- Franklin
_______________________________________________
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) #4

I remember it and remember the disagreements over this simplification too, but I really hope this is now not skipping a full year again.

···

Sent from my iPhone

On 22 Feb 2017, at 08:49, Charlie Monroe <charlie@charliemonroe.net> wrote:

This was pointed out during the discussions surrounding this proposal and it was agreed that the type simplification was important.

There were several suggestions how to bring this back using different features - e.g. compound names that would contain the labels. For example:

let callback(success:error:): (Bool, Error?) -> Void = ...
callback(success: true, error: nil)

This way the type itself wouldn't contain the label information, but the name of the variable would.

On Feb 22, 2017, at 9:41 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

I am quite interested in this as well, thanks for bringing it up! It was quite disappointing to fall back to multi argument method calls without labels as it was going against the emphasis on the value of labels in the language as well as decreasing readability of what is supposed to be self documenting code.

Sent from my iPhone

On 22 Feb 2017, at 08:36, Franklin Schrans via swift-evolution <swift-evolution@swift.org> wrote:

Hi,

When SE-0111 was approved, I noticed the implication it had when using closures as callbacks:

Writing
   func foo(completion: (success: Bool) -> Void) {
     completion(success: true)
   }

is no longer possible, because function types can’t have argument labels anymore, and the function has to be written:
   func foo(completion: (Bool) -> Void) {
     completion(true)
   }

which doesn’t look very nice, especially as the number of the arguments increases.

After talking to Chris Lattner about this, he referred me to this email.
I was wondering if there's been any further work or plans in restoring the use of argument labels in closures.

- Franklin
_______________________________________________
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


(Iain Smith) #5

Would this proposed syntax, using argument labels, also be available in function arguments?

e.g
func items(withCompletion completion(success:error:): ([Item]?, NSError?) -> Void) {
  ...
  completion(success: items, error:nil)
}

···

On 22 Feb 2017, at 08:49, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

This was pointed out during the discussions surrounding this proposal and it was agreed that the type simplification was important.

There were several suggestions how to bring this back using different features - e.g. compound names that would contain the labels. For example:

let callback(success:error:): (Bool, Error?) -> Void = ...
callback(success: true, error: nil)

This way the type itself wouldn't contain the label information, but the name of the variable would.

On Feb 22, 2017, at 9:41 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

I am quite interested in this as well, thanks for bringing it up! It was quite disappointing to fall back to multi argument method calls without labels as it was going against the emphasis on the value of labels in the language as well as decreasing readability of what is supposed to be self documenting code.

Sent from my iPhone

On 22 Feb 2017, at 08:36, Franklin Schrans via swift-evolution <swift-evolution@swift.org> wrote:

Hi,

When SE-0111 was approved, I noticed the implication it had when using closures as callbacks:

Writing
   func foo(completion: (success: Bool) -> Void) {
     completion(success: true)
   }

is no longer possible, because function types can’t have argument labels anymore, and the function has to be written:
   func foo(completion: (Bool) -> Void) {
     completion(true)
   }

which doesn’t look very nice, especially as the number of the arguments increases.

After talking to Chris Lattner about this, he referred me to this email.
I was wondering if there's been any further work or plans in restoring the use of argument labels in closures.

- Franklin
_______________________________________________
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


(Franklin Schrans) #6

I don’t see why it should be available in function arguments.

The separation of the type and its label makes sense semantically, but the syntax doesn’t look as pretty anymore.

Writing something like
  foo(completion(success:error:): (Bool, Error) -> Void) {}
seems a bit convoluted to me. We first have to write the labels, then remember their order to write the type.

Minor: this also adds additional complexity when Xcode tries to generate a stub for the closure, as it needs to find the labels in the function name.

I was thinking of an implementation where closure types could have labels, but these could only be used within the body of that closure and would be erased elsewhere. This however still makes it difficult for the caller to figure out what each argument in the closure is representing when using foo.

- Franklin

···

On Feb 22, 2017, at 9:05 AM, Iain Smith via swift-evolution <swift-evolution@swift.org> wrote:

Would this proposed syntax, using argument labels, also be available in function arguments?

e.g
func items(withCompletion completion(success:error:): ([Item]?, NSError?) -> Void) {
  ...
  completion(success: items, error:nil)
}

On 22 Feb 2017, at 08:49, Charlie Monroe via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

This was pointed out during the discussions surrounding this proposal and it was agreed that the type simplification was important.

There were several suggestions how to bring this back using different features - e.g. compound names that would contain the labels. For example:

let callback(success:error:): (Bool, Error?) -> Void = ...
callback(success: true, error: nil)

This way the type itself wouldn't contain the label information, but the name of the variable would.

On Feb 22, 2017, at 9:41 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I am quite interested in this as well, thanks for bringing it up! It was quite disappointing to fall back to multi argument method calls without labels as it was going against the emphasis on the value of labels in the language as well as decreasing readability of what is supposed to be self documenting code.

Sent from my iPhone

On 22 Feb 2017, at 08:36, Franklin Schrans via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi,

When SE-0111 <https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md> was approved, I noticed the implication it had when using closures as callbacks:

Writing
   func foo(completion: (success: Bool) -> Void) {
     completion(success: true)
   }

is no longer possible, because function types can’t have argument labels anymore, and the function has to be written:
   func foo(completion: (Bool) -> Void) {
     completion(true)
   }

which doesn’t look very nice, especially as the number of the arguments increases.

After talking to Chris Lattner about this, he referred me to this <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html> email.
I was wondering if there's been any further work or plans in restoring the use of argument labels in closures.

- Franklin
_______________________________________________
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


(Derrick Ho) #7

Argument labels on blocks arguments should be brought back.

···

On Wed, Feb 22, 2017 at 4:26 AM Franklin Schrans via swift-evolution < swift-evolution@swift.org> wrote:

I don’t see why it should be available in function arguments.

The separation of the type and its label makes sense semantically, but the
syntax doesn’t look as pretty anymore.

Writing something like
  foo(completion(success:error:): (Bool, Error) -> Void) {}
seems a bit convoluted to me. We first have to write the labels, then
remember their order to write the type.

Minor: this also adds additional complexity when Xcode tries to generate a
stub for the closure, as it needs to find the labels in the function name.

I was thinking of an implementation where closure types could have labels,
but these could only be used within the body of that closure and would be
*erased* elsewhere. This however still makes it difficult for the caller
to figure out what each argument in the closure is representing when using
foo.

- Franklin

On Feb 22, 2017, at 9:05 AM, Iain Smith via swift-evolution < > swift-evolution@swift.org> wrote:

Would this proposed syntax, using argument labels, also be available in
function arguments?

e.g
func items(withCompletion completion(success:error:): ([Item]?, NSError?)
-> Void) {
  ...
  completion(success: items, error:nil)
}

On 22 Feb 2017, at 08:49, Charlie Monroe via swift-evolution < > swift-evolution@swift.org> wrote:

This was pointed out during the discussions surrounding this proposal and
it was agreed that the type simplification was important.

There were several suggestions how to bring this back using different
features - e.g. compound names that would contain the labels. For example:

let callback(success:error:): (Bool, Error?) -> Void = ...
callback(success: true, error: nil)

This way the type itself wouldn't contain the label information, but the
name of the variable would.

On Feb 22, 2017, at 9:41 AM, Goffredo Marocchi via swift-evolution < > swift-evolution@swift.org> wrote:

I am quite interested in this as well, thanks for bringing it up! It was
quite disappointing to fall back to multi argument method calls without
labels as it was going against the emphasis on the value of labels in the
language as well as decreasing readability of what is supposed to be self
documenting code.

Sent from my iPhone

On 22 Feb 2017, at 08:36, Franklin Schrans via swift-evolution < > swift-evolution@swift.org> wrote:

Hi,

When SE-0111
<https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md> was
approved, I noticed the implication it had when using closures as callbacks:

Writing
   func foo(completion: (success: Bool) -> Void) {
     completion(success: true)
   }

is no longer possible, because function types can’t have argument labels
anymore, and the function has to be written:
   func foo(completion: (Bool) -> Void) {
     completion(true)
   }

which doesn’t look very nice, especially as the number of the arguments
increases.

After talking to Chris Lattner about this, he referred me to this
<https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024331.html>
email.
I was wondering if there's been any further work or plans in restoring the
use of argument labels in closures.

- Franklin

_______________________________________________
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