子协议中关联类型定义与泛型约束的差异及报错解析

问题背景 #

在继承自CRUDRepository的子协议中，两种关联类型定义方式存在本质差异，导致TestB出现如下报错：

Member 'read' cannot be used on value of type 'any RepositoryB'; consider using a generic constraint instead

从实现类RepositoryAImpl与RepositoryBImpl的代码来看，二者实现逻辑看似一致，但底层约束逻辑完全不同，以下是详细解析。

示例代码 #

public protocol CRUDRepository {
    associatedtype Item
    associatedtype ReadInput
    
    func create(_ item: Item) async throws
    func read(_ input: ReadInput) -> AsyncThrowingStream<[Item], Error>
    func update(_ item: Item) async throws
    func delete(_ item: Item) async throws
}

// 方式1：使用泛型约束固定关联类型
public protocol RepositoryA: CRUDRepository where Item == String, ReadInput == Query {}

// 方式2：给关联类型设置默认值
public protocol RepositoryB: CRUDRepository {
    associatedtype Item = String
    associatedtype ReadInput = Query
}

public struct Query {}

// RepositoryA的实现类
struct RepositoryAImpl: RepositoryA {
    func create(_ item: String) async throws {}
    
    func read(_ input: Query) -> AsyncThrowingStream<[String], Error> {
        AsyncThrowingStream { continuation in
            continuation.yield(["Test"])
        }
    }
    
    func update(_ item: String) async throws {}
    func delete(_ item: String) async throws {}
}

// RepositoryB的实现类
struct RepositoryBImpl: RepositoryB {
    func create(_ item: String) async throws {}
    
    func read(_ input: Query) -> AsyncThrowingStream<[String], Error> {
        AsyncThrowingStream { continuation in
            continuation.yield(["Test"])
        }
    }
    
    func update(_ item: String) async throws {}
    func delete(_ item: String) async throws {}
}

// 可正常编译的TestA
struct TestA {
    private let repository: any RepositoryA
    init(repository: any RepositoryA) {
        self.repository = repository
    }
    
    func start() -> AsyncThrowingStream<[String], Error> {
        repository.read(Query())
    }
}

// 编译报错的TestB
struct TestB {
    private let repository: any RepositoryB
    init(repository: any RepositoryB) {
        self.repository = repository
    }
    
    func start() -> AsyncThrowingStream<[String], Error> {
        repository.read(Query()) // 此处报错
    }
}

核心差异解析 #

1. 泛型约束（RepositoryA）：强制固定关联类型 #

RepositoryA通过where子句直接约束Item必须为String、ReadInput必须为Query，这意味着：

• 所有实现RepositoryA的类型没有任何选择余地，必须严格遵循这两个关联类型的定义；
• any RepositoryA是一个确定的存在类型，编译器可以明确知道该类型的Item和ReadInput的具体类型，因此调用read(Query())时，能完全匹配方法参数要求，不会出现歧义。

2. 关联类型默认值（RepositoryB）：仅提供默认选项，保留灵活性 #

RepositoryB给关联类型设置的默认值，只是给实现类提供了一个“偷懒”的选项——如果实现类不主动指定关联类型，就会使用默认的String和Query，但本质上：

• 协议本身仍然是泛型协议，实现类可以自由重写关联类型，比如：

  struct AnotherRepoB: RepositoryB {
      typealias Item = Int
      typealias ReadInput = Int
      
      func create(_ item: Int) async throws {}
      func read(_ input: Int) -> AsyncThrowingStream<[Int], Error> {
          AsyncThrowingStream { $0.yield([123]) }
      }
      // 其他方法实现...
  }
  

  这个实现完全合法，但它的read方法参数是Int，而非Query；
• any RepositoryB作为存在类型，编译器无法确定它背后的具体实现是否使用了默认关联类型，因此无法保证read(Query())的调用是安全的，直接报错提示需要用泛型约束来固定类型。

实现类要求的表象与本质 #

从RepositoryAImpl和RepositoryBImpl的代码来看，二者确实都实现了基于String和Query的方法，但：

• RepositoryAImpl是必须这么做，协议强制约束了类型；
• RepositoryBImpl是可选这么做，它只是用了协议的默认值，随时可以改成其他类型。

解决TestB报错的两种方式 #

如果要让TestB正常工作，有两种可行方案：

1. 把RepositoryB改成和RepositoryA一样的泛型约束方式：

   public protocol RepositoryB: CRUDRepository where Item == String, ReadInput == Query {}
   

2. 给TestB添加泛型约束，固定关联类型：

   struct TestB<T: RepositoryB> where T.Item == String, T.ReadInput == Query {
       private let repository: T
       init(repository: T) {
           self.repository = repository
       }
       
       func start() -> AsyncThrowingStream<[String], Error> {
           repository.read(Query())
       }
   }
   

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