The feedback was light but very positive, with some great questions and discussion in the thread. The core team has accepted the proposal, but agree with Ben Rimmington that optional completion handlers should imply @discardableResult. The proposal is accepted with that change.
Thank you to the proposal author and to everyone who participated in the review, and happy holidays!
Funny how this has been accepted before the async/await proposal. Looks like out of order results are to be expected when you introduce concurrency in a system.
The proposal notes that these should accessible in the nightly main builds but I don't see any of the APIs in autocomplete. Is it a really narrow subset, or is there a way to enable the async overlay?
With the latest nightly (2021-01-19-a) and -Xfrontend -enable-experimental-concurrency I can complete fileProviderConnection() async throws from Foundation in the below (chosen at random from the Foundation API changes):
import Foundation
func asyncFoo(x: NSFileProviderService) async {
x.
}
Is there a specific API you are not seeing translated correctly?
Yes, URLSession. It does look like I can see other async APIs, like the PassKit example from the proposal. I'll take a look at the API changes to see what should be there for sure.
Sorry for coming late to the party but upon rereading the proposal I had a small question.
Completion handlers must be called exactly once
...
While this does not fix the underlying problem, it can at least detect the issue consistently at run time.
Has there been any discussion at what this detection will result in practice? Xcode runtime warnings, logs in the console, assertions on debug...?