Re: ARC dealloc best pratice
Re: ARC dealloc best pratice
- Subject: Re: ARC dealloc best pratice
- From: Greg Parker <email@hidden>
- Date: Fri, 06 Feb 2015 14:00:17 -0800
> On Feb 6, 2015, at 1:48 PM, Jonathan Mitchell <email@hidden> wrote:
>
>> On 6 Feb 2015, at 21:31, Greg Parker <email@hidden> wrote:
>>
>>> Come to think of it, I'm surprised that AppKit delegates are still unsafe-unretained. Why haven't these been converted to safe weak references yet?
>>
>> Some classes are incompatible with (safe zeroing) weak references. For example, any class that implements custom retain count storage needs additional code to work with weak references. That means AppKit needs to be careful about binary compatibility when it changes an unretained delegate to a weak delegate.
>
> Does Swift avoid unsafe-unretained references entirely or does it rear its head when interacting with Obj-C?
Swift has strong and weak references that work like ARC.
Swift adds "unowned" references. These references are non-retaining. They differ from weak references and unsafe unretained references: unowned references fail with a runtime error if you try to access the pointed-to object after it has been deallocated. They are intended for cases like views pointing back to superviews, where you need to avoid a retain cycle and you "know" the pointed-to object will still be alive whenever you use it. They are cheaper than weak references and safer than unsafe-unretained.
Swift supports unsafe references using things like the UnsafePointer class. Unsafe interactions with C and Objective-C use such classes, so you shouldn't get unsafe references by surprise.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
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