为何@autoclosure @escaping在异步函数中失效？如何修复？

错误原因 #

你碰到的'async' autoclosure parameter in a non-'async' function编译错误，源于Swift的硬性规则：只要函数的@autoclosure参数是异步闭包类型（比如() async -> Void），不管这个参数是否标记@escaping，函数本身必须被声明为async。

这是因为@autoclosure的设计是延迟执行传入的表达式，但编译器无法预判你是否会在当前函数内部执行这个异步闭包——哪怕你现在只是把它存入队列（escaping），规则依然要求函数是异步的，因为异步闭包执行时可能会挂起，而非异步函数无法处理挂起逻辑。

修复方案 #

方案1：放弃@autoclosure，显式传入闭包（最简洁） #

不需要修改原队列的核心逻辑，调用时用闭包包裹异步函数调用即可，这也是Swift异步编程的常规写法：

// 原Queue代码保持不变
class Queue {
    var queue: [() async -> Void] = []
    
    func enqueue(_ operation: @escaping () async -> Void) {
        queue.append(operation)
    }
}

// 带参数的异步函数
func networkCall(duration: UInt64) async {
    try? await Task.sleep(nanoseconds: duration * 1_000_000_000)
}

// 调用示例
let queue = Queue()
queue.enqueue { await networkCall(duration: 2) }

方案2：保留目标调用写法，调整参数类型 #

如果一定要实现queue.enqueue(networkCall(duration: 2))的调用形式，可以把@autoclosure的返回类型改为Task<Void, Never>，利用Swift自动创建Task的特性规避异步autoclosure的限制：

class Queue {
    var queue: [() async -> Void] = []
    
    func enqueue(_ operation: @autoclosure @escaping () -> Task<Void, Never>) {
        // 将Task的等待逻辑包装成队列需要的异步闭包
        queue.append {
            await operation().value
        }
    }
}

// 调用方式完全符合你的期望
queue.enqueue(networkCall(duration: 2))

这里的原理是：在非异步上下文直接调用异步函数时，Swift会自动创建一个Task，@autoclosure把这个表达式包装成同步闭包，既满足了你的调用写法，又避开了异步autoclosure的规则限制。

内容的提问来源于stack exchange，提问作者rayaantaneja