[swift-evolution] Improved Trailing Closure Syntax

Dave Abrahams dabrahams at apple.com
Thu Dec 29 00:28:06 CST 2016


on Wed Dec 28 2016, Nicholas Maccharoli <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.

Usage would be better as:

   onNext { event in ... }
   onError { event in ... }

which makes this example a non-problem.  I think there are real use
cases for mandatory labels on *some* trailing closures (e.g. when there
are multiple parameters of function type, especially if some have
default values), but... this ain't a compelling example of that.

-- 
-Dave



More information about the swift-evolution mailing list