Async feedback: overloads that differ only in async

Evolution Discussion
3

A dummy parameter and @_disfavoredOverload did the trick:

public protocol DatabaseReader: AnyObject {
    @_disfavoredOverload
    func read<T>(_ block: (Database) throws -> T) throws -> T
}

#if swift(>=5.5)
@available(macOS 12, iOS 15, tvOS 15, watchOS 8, *)
extension DatabaseReader {
    public func read<T>(_ignored: Void = (), _ value: @escaping (Database) throws -> T) async throws -> T { ... }
}
#endif

Now I can both read { ... ) and await read { ... } :tada:

However, I had to both use @_disfavoredOverload (non-public), and expose a "dirty" async variant.

Now I think I can directly call @John_McCall and @Douglas_Gregor. There exists a workaround to the overloads that differ only in async limitation. So people will use it. I plan to use it. Would you consider removing the limitation, so that we are not forced to use this ugly workaround?

14 Likes