[swift-evolution] Improved Trailing Closure Syntax

[Jeff Kelley]

You can do this now. Since you can get a reference to the function you want
by writing something like let function = subscribe(onNext:), you can do so
and immediately call it:

struct Event: CustomStringConvertible {

    var description: String {

        return "an event"

    }

}


func subscribe(onNext block: @escaping (Event) -> Void)  {

    block(Event())

}


func subscribe(onError block: @escaping (Event) -> Void) {



}


func subscribe(onCompleted block: @escaping (Event) -> Void) {



}


subscribe(onNext:) { event in

    print("Subscribed to \(event)")

}

In a playground on Xcode 8.2.1, this prints “*Subscribed to an event*” in
the console.


Jeff Kelley

SlaunchaMan at gmail.com | @SlaunchaMan <https://twitter.com/SlaunchaMan> |
jeffkelley.org

On Wed, Dec 28, 2016 at 11:58 PM, Nicholas Maccharoli via swift-evolution <
swift-evolution at swift.org> wrote:

> Swift Evolution,
>
> Swift's API Design Guidelines are really good in my opinion, but I believe
> there is
> ambiguity with current trailing closure syntax.
>
> Take for example if there were three variations of a `subscribe`function:
>
>      func subscribe(onNext block: @escaping (Event) -> Void)  { ... }
>
>      func subscribe(onError block: @escaping (Event) -> Void) { ... }
>
>      func subscribe(onCompleted block: @escaping (Event) -> Void) { ... }
>
> Since using subscribe with trailing closure syntax would cause ambiguity:
>
>      subscribe { event in ... }
>
> The only option available is to call the function as normal:
>
>      subscribe(onNext: { event in ... })
>
> Since these functions are distinguished by their argument label, if a
> variation of trailing closure syntax were introduced that provided the
> option of using an argument label in parenthesis this ambiguity would
> disappear.
>
> something like this:
>
>      subscribe(onNext:) { event in ... }
>
> would allow using trailing closure syntax in this case.
>
> Just a thought, I personally think having this change to the language
> would be worthwhile but would love to hear the community's opinion.
>
> - Nick
>
>
>
>
>
> _______________________________________________
> 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/20161229/50169f9c/attachment.html>