Re: Who owns a child view controller?
Re: Who owns a child view controller?
- Subject: Re: Who owns a child view controller?
- From: Jeremy Hughes <email@hidden>
- Date: Thu, 13 Jul 2017 11:26:12 +0100
> On 13 Jul 2017, at 10:57, Jeremy Hughes <email@hidden> wrote:
>
> Apple’s Swift book says:
>
> "The examples above show how to use safe unowned references. Swift also
> provides unsafe unowned references for cases where you need to disable
> runtime safety checks—for example, for performance reasons. As with all
> unsafe operations, you take on the responsiblity for checking that code for
> safety.
>
> "You indicate an unsafe unowned reference by writing unowned(unsafe). If you
> try to access an unsafe unowned reference after the instance that it refers
> to is deallocated, your program will try to access the memory location where
> the instance used to be, which is an unsafe operation.”
>
> At this point I’m pretty confused about the difference between strong and
> safe unowned. I understand that strong retains its reference, but it seems to
> me that Dave Abrahams and Apple’s Swift book are saying or implying that
> (safe) unowned also retains its reference - so the consequence of using
> (safe) unowned incorrectly is that it will create a retain cycle, whereas
> using unowned(unsafe) incorrectly will crash. But if unowned(safe) retains
> its reference, how is it different from strong (apart from whether ARC is
> currently optimising for it)?
That last paragraph is wrong, since the Swift book also says:
"IMPORTANT
Use an unowned reference only when you are sure that the reference always
refers to an instance that has not been deallocated.
If you try to access the value of an unowned reference after that instance has
been deallocated, you’ll get a runtime error.”
So perhaps the difference between safe and unsafe unowned is that safe unowned
generates a runtime error (but doesn’t crash) while unsafe unowned crashes? Or
perhaps they both crash, but unowned(unsafe) gives a more helpful error message?
Jeremy
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden