{"id":44215,"date":"2024-07-25T14:24:45","date_gmt":"2024-07-25T18:24:45","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=44215"},"modified":"2024-07-25T14:24:45","modified_gmt":"2024-07-25T18:24:45","slug":"swifts-anyobject","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/07\/25\/swifts-anyobject\/","title":{"rendered":"Swift’s AnyObject"},"content":{"rendered":"

Jordan Rose<\/a>:<\/p>\n

\n

You can also use AnyObject as a constraint on protocols: protocol MyDelegate: AnyObject<\/code>. Now the implementers are known to have reference semantics, and with T: MyDelegate<\/code> you can have weak references to T, as before. You can even have weak references to any MyDelegate<\/code>, allowing swapping between delegates of different types.<\/p>\n\n

What you might run into, though, is that any MyDelegate<\/code> is not itself AnyObject.<\/p>\n

[…]<\/p>\n

Because it carries more information than just a single object reference: it also has a “witness table” pointer, the run-time representation of a protocol conformance.<\/p>\n

[…]<\/p>\n

But wait, Objective-C never had this problem! The id <MyDelegate><\/code> type doesn’t take up more than a single-object-reference to store! But that’s because ObjC protocols aren’t represented as tables of methods; they’re just promises that the implementing class has<\/em> methods with particular names.<\/p>\n<\/blockquote>\n\n

Previously:<\/p>\n