ios - 在 Swift 中使用泛型重载包装函数

Question

第一个示例

func foo<T>(_ t: T) -> String {
    return bar(t)
}

func bar<T>(_ t: T) -> String {
    return "Other"
}

func bar<T: StringProtocol>(_ t: T) -> String {
    return "String"
}

foo("") // "Other" // Why not "String"?
bar("") // "String"
bar(1) // "Other"

第二个示例(更复杂)

第一个示例可以通过类型检查来解决，但在这个示例中这是不可能的。

func foo<T>(_ t: (T) -> String) -> String {
    return bar(t)
}

func bar<T>(_ t: (T) -> String) -> String {
    return "Other"
}

func bar<T: StringProtocol>(_ t: (T) -> String) -> String {
    return "String"
}

foo { (string: String) -> String in return "" } // Other // Why not "String"?
bar { (string: String) -> String in return "" } // String
bar { (int: Int) -> String in return "" } // Other

重载是静态解决的。由于 foo() 内的 T 不受约束，因此它会使用不受约束的 T 选择 bar() 的重载。有任何解决方法吗？

Answer 1

根据当前的 Swift 实现，该函数更加专业，这意味着它具有约束，这些约束是其他重载函数的约束的超集；重载将选择更专业的函数。

所以，我想不出比使 foo 符合 StringProtocol 更好的选择。

关于为什么没有更好的 hack，我想引用 Swift documentation 的话。其中讨论了应如何解析嵌套或更专门的泛型类型。:

This amounts to run-time overload resolution, which may be desirable, but also has downsides, such as the potential for run-time failures due to ambiguities and the cost of performing such an expensive operation at these call sites. Of course, that cost could be mitigated in hot generic functions via the specialization mentioned above.

Our current proposal for this is to decide statically which function is called (based on similar partial-ordering rules as used in C++), and avoid run-time overload resolution. If this proves onerous, we can revisit the decision later.