将 *generic* 协议桥接到 Objective-C 的解决方法？答案

【问题标题】：Workaround to bridge a *generic* protocol to Objective-C?将 *generic* 协议桥接到 Objective-C 的解决方法？
【发布时间】：2018-06-26 23:12:14
【问题描述】：

假设我们有以下 Objective-C API：

- (id)foo:(Protocol *)proto;

导入到 Swift 中的是：

func foo(_ proto: Protocol) -> Any

是的，它是为我们提供代理对象的其中之一。在 Swift 中使用这些往往很烦人，所以假设我们想要对这个东西进行包装以使其更友好一些。首先我们定义了几个 Objective-C 兼容的协议：

@objc protocol Super {}
@objc protocol Sub: Super {}

现在，我们定义一个函数，它接受一个符合Super 的协议并将其传递给foo()，然后我们以Sub 作为参数调用它，看看它是否有效：

func bar<P: Super>(proto: P.Type) {
    let proxy = foo(proto)

    // do whatever with the proxy
}

bar(proto: Sub.self)

好吧，这不会编译。给出的错误信息是：

error: cannot convert value of type 'P.Type' to expected argument type 'Protocol'

这是做（大部分）编译的一些东西：

func bar<P: Super>(proto: P.Type) {
    // when called with 'Sub.self' as 'proto':

    print(type(of: proto))    // Sub.Protocol
    print(type(of: Sub.self)) // Sub.Protocol
    print(proto == Sub.self)  // true

    let proxy1 = foo(Sub.self) // compiles, runs, works
    let proxy2 = foo(proto) // error: cannot convert value of type 'P.Type' to expected argument type 'Protocol'
}

好的，它几乎在所有方面都与Sub.self 相同，只是我不能将它传递给需要Objective-C 协议的东西。嗯。

问题在于，尽管Sub 符合Super 的事实意味着它必须是一个Objective-C 协议，但编译器并没有意识到这一点。我们可以解决这个问题并手动桥接它吗？好吧，我们来看看Protocol的界面，看看有没有什么可以...

OBJC_AVAILABLE(10.0, 2.0, 9.0, 1.0, 2.0)
@interface Protocol : NSObject
@end

哦。嗯。

嗯，Protocol 是一个成熟的NSObject 子类这一事实表明，这可能都是我最喜欢的功能的工作，神奇的 SwiftObjective-C 桥执行非平凡的转换在事情不明显的情况下发生了什么。好吧，这至少给了我一个想法；我应该能够通过强制转换为AnyObject 来手动调用桥接器，并希望通过as! 或其他方式获得Protocol 对象。有用吗？

print(Sub.self as AnyObject)  // <Protocol: 0x012345678>

嗯，这很有希望。当我在我的泛型参数上尝试它时？

print(proto as AnyObject) // Terminated due to signal: SEGMENTATION FAULT (11)

哦，来吧上。

我怀疑这可能是编译器中的一个错误，我计划测试一些东西以确定是否是这种情况，但由于 Swift 源代码需要很长时间才能编译，所以我想我会在这里发布这个我在等待。有人对这里发生的事情有任何见解和/或解决方法吗？

【问题讨论】：

标签： swift objective-c-runtime

【解决方案1】：

我知道它并不漂亮和“Swifty”，确切地说，但是可以使用 NSProtocolFromString 来获得适合传递到 foo 的 Objective-C Protocol，如下所示：

let proxy2 = foo(NSProtocolFromString(String(reflecting: proto))!)

其中String(reflecting:) 是获取适合通过NSProtocolFromString 解析的完全限定类型名称的有用方法。

我会说你遇到的崩溃是一个错误。

【讨论】：

有效！我试过Mirror(reflecting: proto).subjectType，但这当然省略了作为协议完整Objective-C名称一部分的模块名称。如果实际上指定了一个自定义的 Objective-C 名称，如@objc(Foo)，则有一个问题，String(reflecting:) 的输出将在前面加上 __C. 前缀，该前缀必须被删除。此外，这似乎是半无证的，所以我不确定我是否想在生产代码中依赖它，但这可能是一个很好的临时解决方法，直到如果没有人想出更好的解决方案来修复崩溃。谢谢！

【解决方案2】：

好的，在进一步调查之后，我确定它确实是一个编译器错误，并且有filed a report on it: SR-8129。似乎正在发生的事情是 Swift 编译器错误地假设proto 将始终是具体class 类型的元类型，因此它通过发出对swift_getObjCClassFromMetadata 的调用来执行桥接，当它遇到协议时崩溃元类型。当Sub.self 显式转换为AnyObject 时，编译器会发出Swift._bridgeAnythingToObjectiveC<A>(A) -> Swift.AnyObject，这似乎是动态确定对象的类型并相应地桥接它。

考虑到这一点，解决方法变得显而易见：首先将proto 转换为Any，以破坏与泛型关联的类型信息并强制编译器发出Swift._bridgeAnythingToObjectiveC<A>(A) -> Swift.AnyObject。事实上，这似乎有效：

func bar<P: Super>(proto: P.Type) {
    foo(proto as Any as AnyObject as! Protocol)
}

不是最漂亮的东西，但可能比通过字符串操作查找协议更可取。

【讨论】：