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
dabrahams
(Dave Abrahams)
2
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.
···
on Wed Dec 28 2016, Nicholas Maccharoli <swift-evolution@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.
--
-Dave
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@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@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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
