您能在Swift中为特定泛型类型提供协议扩展吗？

使用协议扩展，我可以使任何对象符合我自己的协议，只要我为此提供一个实现。例如，假设我创建了一个协议：

protocol Printable {
    // ... whatever ...
}

现在我可以像这样打印字符串和整数：

extension String: Printable {
    // ... whatever is required to satisfy protocol ...
}

extension Int: Printable {
    // ... whatever is required to satisfy protocol ...
}

这是一种非常酷的编程方式，因为我现在可以将字符串和int输入到任何可以处理可打印内容的函数中

现在，如果我有一个可打印的数组，那么整个数组都是可打印的，所以我尝试这样做：

extension Array<Printable>: Printable {
    // ... whatever is required to satisfy protocol ...
}

---

这正如预期的那样有效。我在上面扩展中输入的内容只适用于可打印元素的数组。但这不会使可打印元素数组符合可打印协议本身。这只是一个普通的扩展，而不是所谓的“协议扩展”。

您可以在Swift 4.1中执行此操作

extension Array: Printable where Element: Printable {
    // ...
}

---

您不能有条件一致性。@RMenke为什么不将其作为答复写下来？你确定吗？因为据我所知，

Array

和

Array

实际上是Swift类型系统中完全不同的类型，所以在理论上不同的类型可以有不同的一致性——毕竟它们也可以有不同的扩展。如果这是不可能的，我应该认真地申请Swift 3.0，因为这在许多情况下都是一个重要的功能。我并没有将其作为答复，因为这实际上是一个重复的问题；）。我确信这一点<代码>数组和

数组

属于同一类型。只是为

typealias元素

使用了不同的类型。自Swift 2.0发布以来，也有人要求有条件的一致性，但至今还没有发生。@RMenke即使是一个傻瓜，你也不会因为回答这个问题而受到惩罚，当它以傻瓜的身份关闭时，你也不会失去任何声誉：）如果你写了一个真实的答案，我会给你一个提升票；）如果泛型不是不同的类型，它们怎么会有不同的扩展？编译器如何知道它们有，因为它在编译时已经知道函数是否可用，这只取决于

元素的类型。所以编译器在这里必须有一些特殊的逻辑，使用完全相同的逻辑，它也可以在理论上测试一致性。在最后一部分，我完全同意你的观点。很多时候，我开始以一种更面向协议的方式重构一些东西，然后撞上这堵墙，我知道这堵墙，它现在已经烙印在我的脸上了。我很高兴现在我们有了带约束的扩展。显然，以前版本的Swift不可能实现这一点，所以这是正确的答案。我做得像'Element==Printable'一样错误，并收到了错误消息
extension Array: Printable where Element: Printable {
    // ...
}