<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On Apr 30, 2017, at 4:43 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">On Apr 30, 2017, at 11:57 AM, Charles Srstka via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:<br class=""><br class="">What does the community think? Should I file this as a bug on Swift? Foundation? AppKit? All three?<br class=""></blockquote><br class="">I would file it against AppKit. Once it's in Radar, they can kick the can over to Foundation or Swift, but it's trickier to do the opposite.</div></div></blockquote><br class=""></div>Thought about it a bit, and it really is two separate issues. AppKit probably *shouldn’t* be using NSCopyObject to copy things, and Swift shouldn’t be crashing if it does. So, I’ve filed a bug report on each:<div class=""><br class=""></div><div class=""><a href="rdar://31912100" class="">rdar://31912100</a></div><div class=""><a href="https://bugs.swift.org/browse/SR-4756" class="">https://bugs.swift.org/browse/SR-4756</a></div><div class=""><br class=""></div><div class="">In the event that anyone with the same problem (which, if anyone’s curious, was implementing a custom field editor, the only customization point for which is on NSCell rather than NSControl) discovers this thread, let me save you a little time on some workarounds that don’t work:</div><div class=""><br class=""></div><div class=""><div class="">Implementing your own copy(with:) method fails, because you need to call super’s implementation to copy the cell effectively, and the crash will still occur.</div><div class=""><br class=""></div><div class="">Using a weak property to the containing NSControl and putting your stored properties there doesn't work, because NSCopyObject doesn't seem to play nice with weak variables either, and all sorts of errors will be logged to the console.</div><div class=""><br class=""></div><div class="">Using an unowned property to the containing NSControl doesn't work, because unowned properties cannot be null, and the connection will not be made until runtime.</div><div class=""><br class=""></div><div class="">Making a non-Objective-C property and storing your Objective-C properties inside it seemed to work some of the time, and crashed other times, when I tried it. I haven’t studied the low-level layout of Swift objects enough to know why this was.</div><div class=""><br class=""></div><div class="">What works is to use Objective-C associated objects. Use objc_getAssociatedObject in the getter and objc_setAssociatedObject in the setter. Be sure to use withUnsafeMutableBytes on your key property and pass its baseAddress as the key, because the associated object functions take immutable pointers, and since your key property has to be a var to ensure it stays unique, just passing it via & character will cause Swift to make an immutable copy first, and then pass a pointer to *that*, and things won’t work.</div></div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>