> On Feb 6, 2015, at 1:48 PM, Jonathan Mitchell <jonat...@mugginsoft.com> wrote: > >> On 6 Feb 2015, at 21:31, Greg Parker <gpar...@apple.com> 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 gpar...@apple.com Runtime Wrangler _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
