Hello Swift Community,
It was generally accepted that overloading on
async would be beneficial. Most of the discussion centered not on
async, but on
throws. Accepting this amendment makes
async more different from
throws, and there was some sentiment that this amendment should only be accepted if we also allow overloading on
throws accordingly. The Core Team disagreed with this approach for two specific reasons:
throwsis not necessarily as amenable to overloading as
async, due to the presence of control flow that handles thrown errors without requiring the enclosing context to be
catchconstructs have no analogy in
async). It is not a given that
asyncmust be consistent with respect to their overloading behavior.
- Second, overloading on
asyncis timely in a way that
throwsis not. There are no
asyncAPIs now, but the Swift community will be adding them as soon as Swift 5.5 becomes available. Without overloading on
async, the Swift ecosystem will end up with a nontrivial number of APIs with non-ideal names (e.g., an
Asyncsuffix) that won't be able to be fixed later.
throwsis different, because the overloading rule has been in place since Swift 2.0. Delaying the ability to overload on
asynchas long-term costs that the Core Team feels are not justified by the potential for inconsistency.
The Core Team is amenable to considering a proposal for overloading on
throws, separately from this amendment. Part of the motivation for such a proposal can be consistency with
async. However, such a proposal should account for the differences in semantics, and also consider the source-compatibility ramifications of making such a change.
Thank you to everyone who participated in the review!