Joe Groff
@robtimp @jesse_squires Unowned is faster and allows for immutability and nonoptionality. If you don't need weak, don't use it.
-
@jckarter ah, so the second refcount tracks how many things refer to that unowned object?
Chris Eidhof
@chriseidhof Yeah, so we can check whether the object is still alive before strong-retaining it again.
-
-
@jckarter wait, so as long as there's an unowned ref, memory isn't freed? How does unowned prevent ref cycles then? -
@jckarter when A refers B strongly, and B refers A unowned, it still creates a cycle? Because A only is released after unowned releases? - View other replies
-
@chriseidhof The object is destroyed and gives up all its resources when the last strong reference is released. - View other replies
-
@chriseidhof The memory for the instance is still allocated but left in a zombie state. - View other replies
-
@jckarter@chriseidhof just to clarify: does `unowned` behave basically like `assign` in objc? -
@heathborders@chriseidhof The property doesn't keep the object alive, but the runtime still validates access to the dead object. -
@jckarter@chriseidhof so if the object is dead when you access it, swift guarantees a crash whereas objc doesn't? - View other replies
- Show more
-
-
-
@jckarter@chriseidhof Is there any place where this is documented? I’m sure will be useful. -
@marc_huguet@jckarter I think it'll be documented in the Swift source code once it's out! =) -
@chriseidhof@jckarter Really looking forward to see what and how they will open source Swift :)
-
Heath Borders
marc_huguet
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.