[swift-evolution] Argument labels in callbacks

Derrick Ho wh1pch81n at gmail.com
Wed Feb 22 07:34:25 CST 2017


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 at 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 at 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 at 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 at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170222/6316f40e/attachment.html>


More information about the swift-evolution mailing list