On Jul 14, 2017, at 03:32 , Jeremy Hughes <moon.rab...@virginmedia.com> wrote: > > one might argue that safe unowned objects could be replaced by > unowned(unsafe) objects in release code
It’s highly desirable not to do that, because it’s the bugs that show up in release code that are the hardest to find. In fact, Swift has a “stronger” level of optimizations called “unsafe”, where the compiler just omits many of the safety checks that you normally get even in release code. Whether this turns of unowned reference counts is unknown to me. It’s important (for compiler writers) to reason correctly in this area. Your source code might have a couple of variables holding references to a particular object, and one of those variables could by unowned. (There has to be at least one owning reference as well, otherwise the object wouldn’t exist.) But primary retain counts are incremented/decremented basically every time the reference is *used*, which can be thousands or millions of times. Secondary retain counts are incremented/decremented basically once per variable. So, if the reference to a particular object is only every used once per variable, secondary reference counting doubles to overhead, but only on something whose CPU cost is vanishingly small. If the object reference is used a lot, the contribution of the secondary retain count to overhead is vanishingly small. There’s nothing to complain about here. The only scenario I can think of where it might matter is when you’re creating and destroying variables (as opposed to objects) a lot, such as having an “unowned” local variable in the innermost scope of a tight loop. If you do that to avoid the overhead of ARC inside the loop, you’re probably not achieving your intention. But this is a very specialized scenario. > I don’t think an unowned variable can be any kind of optional Yes, it was just wishful thinking on my part. I recently ran into a scenario (a “parent” pointer from a child back to its parent in a tree structure), where a subtree might temporarily and validly have no parent. If the tree can be large (hundreds of thousands of objects), making the “parent” pointer be “weak” starts to become unpalatable, due the (presumed) overhead of a big side-table. OTOH, the lifetime of a non-nil “parent” pointer is guaranteed to be less than the lifetime of a child (because if it has a parent, its parent is retaining it, by definition), so it seems like a good candidate for “unowned”. > I was going to say I think the implicitly unwrapped optional in the Swift > book example is a weak value No, you can create reference cycles with IUOs as easily as with regular variables. :) Again, though, I recommend caution in terminology. I know what you mean here, and I think *you* know what you mean here, but there’s no such thing as a “weak value”. “Weak” is a property of the container, not the contents. _______________________________________________ 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
