SwiftDependencies 项目中 AsyncSequence 与宏的兼容性问题解析

问题背景

在 Swift 并发编程中，AsyncSequence 是一个重要的协议，它允许我们以异步方式处理序列数据。近期，SwiftDependencies 项目中的 eraseToStream() 方法被标记为废弃，开发者需要迁移到使用 any AsyncSequence<Element, Failure> 类型。

问题现象

开发者在使用 @DependencyClient 宏时发现了一个特殊问题：当尝试将 AsyncStream.never 作为 unimplemented 函数的占位符返回时，编译器会报错。有趣的是，单独使用宏或者单独使用 unimplemented 都能正常工作，但两者结合就会出现问题。

技术分析

正常工作情况

1. 不使用宏的情况：

struct Example {
  var exampleSequence: () -> any AsyncSequence<Int, Never> = {
    unimplemented("", placeholder: AsyncStream.never)
  }
}

这种情况下代码能够正常编译。

2. 不使用 unimplemented 的情况：

@DependencyClient
struct Example {
  var exampleSequence: () -> any AsyncSequence<Int, Never> = {
    AsyncStream.never
  }
}

这样也能正常工作。

问题重现

当同时使用宏和 unimplemented 时：

@DependencyClient
struct Example {
  var exampleSequence: () -> any AsyncSequence<Int, Never> = {
    unimplemented("", placeholder: AsyncStream.never)
  }
}

这段代码会导致编译器错误。

深入探究

经过进一步测试发现，这个问题实际上是由 @DependencyEndpoint 宏引起的，而不是整个 @DependencyClient 宏。这表明问题可能出在宏扩展过程中类型推断的某个环节。

临时解决方案

虽然显式类型转换可以解决问题：

AsyncStream.never as any AsyncSequence<Int, Never>

但这种方式不够优雅。

更推荐的临时解决方案是避免使用 unimplemented，直接实现其功能：

struct Example {
  @DependencyEndpoint
  var exampleSequence: () -> any AsyncSequence<Int, Never> = {
    reportIssue()
    return AsyncStream.never
  }
}

根本原因

这实际上是一个 Swift 编译器本身的 bug，特别是在处理宏扩展和存在类型(any AsyncSequence)的类型推断时出现的问题。Swift 的类型系统在处理宏生成的代码和存在类型的组合时出现了不一致性。

对开发者的建议

1. 在等待 Swift 编译器修复期间，可以采用上述的临时解决方案
2. 对于复杂的类型系统交互，特别是涉及宏和存在类型时，保持代码简洁往往能避免这类问题
3. 考虑在项目中建立统一的未实现处理模式，减少对 unimplemented 的依赖

总结

这个问题展示了 Swift 类型系统和宏系统在复杂场景下的微妙交互。虽然存在临时解决方案，但开发者需要意识到这是编译器层面的限制。随着 Swift 语言的不断演进，这类问题有望在未来版本中得到解决。在现阶段，理解问题本质并采用适当的变通方案是保持项目稳定性的关键。