6

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()
}

ああ、それは素晴らしいでしょう！

、、およびの違いweakunowned(safe)unowned(unsafe)に関する詳細情報。

アップデート

上記の機能に関連する素晴らしい Swift の提案を見つけました: Allow using optional binding to upgrade self from a weak to strong reference。

4

1 に答える 1

7

weak突然、Swift での参照が遅くなる可能性があるという当初の前提が間違っていることがわかりました。sourcesからわかるように、Swift は実際にはほぼ同じ実装をweakとunowned参照に使用しています。したがって、weak参照は参照とほぼ同じくらい高速unownedです。

(しかし、Objective-C はまったく別の話です。週参照へのすべてのポインターを追跡するサイドテーブルを使用し、deinit、deallocate、ゼロ化を 1 つのステップとして使用します。また、遅くなる可能性があります。)

このため、私の質問は意味がありません。元の質問の最後のコードで提案したように、週の参照を使用してアンラップする必要があります。

更新:これは、信じられないほどの Mike Ash による素晴らしい記事で、 Swift の内部で参照weakがunownedどのように機能するかを説明しています。

于 2016-01-18T19:16:37.287 に答える