protocol Typographable {
    func setTypography(_ typography: Typography)
}

extension UILabel: Typographable {}

extension Typographable where Self == UILabel {

    func setTypography(_ typography: Typography) {

        self.font = typography.font
        self.textColor = typography.textColor
        self.textAlignment = typography.textAlignment
        self.numberOfLines = typography.numberOfLines
    }
}

我已经创建了一个协议(protocol) Typographable，UILabel 实现了这个协议(protocol)，并且实现在 extension Typographable where Self == UILabel 中.

它在 swift 4.0 中完美运行，但在 swift 4.1 中不再运行，错误消息是 Type 'UILabel' does not conform to protocol 'Typographable'

我仔细阅读了 CHANGELOG swift 4.1，但我找不到任何有用的东西。

这正常吗，我是不是漏掉了什么？

最佳答案

这很有趣。长话短说(好吧也许不是那个短)——它是an intentional side effec吨 #12174 ，它允许返回 Self 的协议(protocol)扩展方法满足非最终类的协议(protocol)要求，这意味着您现在可以在 4.1 中这样说:

protocol P {
  init()
  static func f() -> Self
}

extension P {
  static func f() -> Self {
    return self.init()
  }
}

class C : P {
  required init() {}
}

在 Swift 4.0.3 中，您会在 f() 的扩展实现上遇到一个令人困惑的错误说:

Method 'f()' in non-final class 'C' must return Self to conform to protocol 'P'

这如何适用于您的示例？好吧，考虑一下这个有点类似的例子:

class C {}
class D : C {}

protocol P {
  func copy() -> Self
}

extension P where Self == C {
  func copy() -> C {
    return C()
  }
}

extension C : P {}

let d: P = D()
print(d.copy()) // C (assuming we could actually compile it)

如果 Swift 允许协议(protocol)扩展实现 copy()为了满足要求，我们构建C即使在 D 上调用时也会出现实例例如，破坏协议(protocol)契约。因此 Swift 4.1 将一致性设为非法(为了使第一个示例中的一致性合法)，并且无论是否存在 Self 都会这样做。返回游戏。

其实我们想用扩展名表达的是Self必须是，或继承自 C ，这迫使我们考虑子类使用一致性的情况。

在您的示例中，它看起来像这样:

protocol Typographable {
    func setTypography(_ typography: Typography)
}

extension UILabel: Typographable {}

extension Typographable <b>where Self : UILabel</b> {

    func setTypography(_ typography: Typography) {

        self.font = typography.font
        self.textColor = typography.textColor
        self.textAlignment = typography.textAlignment
        self.numberOfLines = typography.numberOfLines
    }
}

其中，as Martin says ，在 Swift 4.1 中编译得很好。尽管正如 Martin 所说，这可以以更直接的方式重写:

protocol Typographable {
    func setTypography(_ typography: Typography)
}

extension UILabel : Typographable {

    func setTypography(_ typography: Typography) {

        self.font = typography.font
        self.textColor = typography.textColor
        self.textAlignment = typography.textAlignment
        self.numberOfLines = typography.numberOfLines
    }
}

在稍微更技术性的细节中，什么#12174确实允许传播隐式 Self通过见证(符合实现)thunks 的参数。它通过向受限于符合类的 thunk 添加一个通用占位符来实现这一点。

所以对于这样的一致性:

class C {}

protocol P {
  func foo()
}

extension P {
  func foo() {}
}

extension C : P {}

在 Swift 4.0.3 中，C的协议(protocol)见证表(我有 a little ramble on PWTs here 可能有助于理解它们)包含一个指向具有签名的 thunk 的条目:

(C) -> Void

^{(请注意，在我链接到的漫谈中，我跳过了存在 thunk 的细节，只是说 PWT 包含用于满足要求的实现的条目。大部分情况下语义是, 虽然一样)}

但是在 Swift 4.1 中，thunk 的签名现在看起来像这样:

<Self : C>(Self) -> Void

为什么？因为这允许我们传播 Self 的类型信息，允许我们保留要在第一个示例中构造的实例的动态类型(因此使其合法)。

现在，对于如下所示的扩展:

extension P where Self == C {
  func foo() {}
}

与扩展实现的签名不匹配，(C) -> Void , 和 thunk 的签名，<Self : C>(Self) -> Void .因此编译器拒绝一致性(可以说这太严格了，因为 Self 是 C 的子类型，我们可以在这里应用逆变，但这是当前的行为)。

但是，如果我们有扩展名:

extension P where Self : C {
  func foo() {}
}

一切又好了，因为两个签名现在都是 <Self : C>(Self) -> Void .

关于 #12174 的一个有趣的注意事项尽管当需求包含关联类型时，它会保留旧的 thunk 签名。所以这有效:

class C {}

protocol P {
  associatedtype T
  func foo() -> T
}

extension P where Self == C {
  func foo() {} // T is inferred to be Void for C.
}

extension C : P {}

但您可能不应该求助于这种可怕的解决方法。只需将协议(protocol)扩展约束更改为 where Self : C .

关于swift - 不能通过使用 Where 子句创建扩展来符合协议(protocol)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49792626/