Joe Groff

@jckarter sorry to reply to an old tweet, but could you explain why unowned is faster? Is this documented?

@chriseidhof unowned uses a second refcount in the object. weak refs are tracked in a global table.

@jckarter thanks, that clarifies it =)

@chriseidhof It's a space/time tradeoff. unowned can't free memory until unowned refs die, but weak frees immediately when strong refs die.

@jckarter ah, so the second refcount tracks how many things refer to that unowned object?

@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 @robtimp @jesse_squires Noooo! Always favor safety over performance until profiling proves you're in a performance hot spot.

@jckarter @robtimp @jesse_squires 95% of the time, performance is a shiny bauble that makes programmers do stupid things. See Knuth.

@inthehands @robtimp @jesse_squires unowned is also a more accurate model in many cases. Of course you should use the right tool for the job

@jckarter @robtimp @jesse_squires Unowned bypassing the safety benefits of Swift. Users really prefer 1% speed up over not crashing??

@inthehands @robtimp @jesse_squires Unowned means "it isn't correct if this dies." Crashing is the only safe thing if invariants don't hold.

@jckarter @robtimp @jesse_squires And weak forces you to code yourself a safety net if your reasoning about your invariants is incorrect.

@inthehands @robtimp @jesse_squires That's foolish—nil handling code is untestable since it can't happen.

@jckarter @robtimp @jesse_squires Meh, unless you're doing extreme performance code, I disagree. Opens an avenue of error for the programmer

@ketzusaka @robtimp @jesse_squires A non-owning reference is an avenue for error regardless, if it's not correct for the object to go away.

@jckarter True. Curious, how often do you end up in that situation?