swift - 有没有办法检查 `unowned` (实际上是 `unowned(safe)` )引用已被取消？

Question

有什么方法可以检查 unowned(safe) Swift 引用的“可用性”？所以，我在这个例子中寻找一个像 isReferenceAccessible 这样的假设函数:

func someMethod() {
  someAsyncOperation(parameters) { [unowned(safe) self] in 
    guard isReferenceAccessible(self) else {
      return
    }

    self.someAnotherMethod()
  }
}

免责声明:这个问题与weak 引用无关!我知道strong、unowned 和weak 引用有效。而且我不想使用 weak 引用(因为它可能很慢且可变)。我知道 unowned(safe) 引用仍然会被分配，即使当我们试图访问它时它已经被 deinited 了。而且我知道编译器可以执行此检查，并且它会在应用程序崩溃之前实际检查它。

因此，我相信它可以成为打破现代 Swift 中的引用循环的非常强大且性能良好的技术/范例。

此外，我相信它可以成为一个很棒的语言功能!例如，假设我们有一个名为 shared_ownership 的修饰符，它按照上面描述的行为工作:

method(parameters) { [shared_ownership self] in
  self.someAnotherMethod()
}

... 像这样实现:

method(parameters) { [unowned(safe) self] in
  guard isReferenceAccessible(self) else {
    return
  }

  self.someAnotherMethod()
}

... 具有副作用(没有 weak 相关的复杂性和性能损失)等同于:

method(parameters) { [weak self] in
  guard let strongSelf = self else {
    return
  }

  strongSelf.someAnotherMethod()
}

哦，那太棒了!

关于 the differences between weak, unowned(safe), and unowned(unsafe) 的更多信息.

更新

我发现了与上述功能相关的很棒的 Swift 提案:Allow using optional binding to upgrade self from a weak to strong reference .

Answer 1

突然间，我发现我最初的基本假设是错误的，即 Swift 中的 weak 引用可能很慢。从sources可以看出，Swift 实际上对 weak 和 unowned 引用使用了几乎相同的实现。所以 weak 引用几乎和 unowned 引用一样快。

(但是 Objective-C 是完全不同的故事，它使用 sidetable 跟踪所有指向周引用的指针，并将 deinit、deallocate 和 zeroing 作为一个步骤。而且它可能很慢。)

因此，我的问题毫无意义。我必须使用周引用并按照我在原始问题的最后一段代码中提出的建议将其解包。

更新:这里是 an awesome article by incredible Mike Ash that describes how weak and unowned references work under the hood in Swift .